I guess we should figure out how we want our users to read the
documentation. Do we want them to look it up online, generate it
(resttext in docstrings), read the MODULES/README file, etc..
What we should do is work on fixing the modules and figure this out later :)
The only other option I see with that is to have very large amount of
possible keywords to modules that can take lots of options ....
API signatures should most likely take dicts in those cases, and as we
go on we'll have more client side modules
with much less reliance on "call" for the CLI. We certaintly don't
want 12 positional arguments :)
Agreed ... I think (shell wrapping) it's just the easiest thing to do
quickly and it is helpful enough to use. If we can deine some useful
items (esp from the current user base) that are not shell abstracting
we could jump on it quickly. The best ideas out there right now are
the system-config items and yum/rpm item that we could start working
through. I'll try to pick up on one or more of those modules.
Anything new needs to be as API based as possible so that we do not
continue the trend, as it's gruntwork
to clean up later that no one wants to do. This should probably be a
priority to get this done
before we expand the core too much. Standardizing (or improving) the
returns (doing things that
are key/value hash based -- complex data structures) versus splitting
shell lines should also be important, though
as we do this we'll need to write the corresponding features into
things like "show" so the CLI remains
human readable (even though that is not the sole focus, it will be for
many people).
system-config is a bit complex and it would be worthwhile getting
everyone together for a quick
hackfest/meeting for what we want to do about that.
(Obviously this leaves out some non-local IRC friends, but IRC doesn't
quite scale for SW design...)
I would much rather see that happen now than adding a bunch of
documentation about how those commands work, especially as we are
starting to see other applications start building themselves
around Func.
My group already has a few :-)
Some of that may be a good fit for the Wiki?
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
