Am 16.06.2014 20:19, schrieb Bob Tolbert:
On Monday, 16 June 2014 at 17:59:13 UTC, Sönke Ludwig wrote:
Am 15.06.2014 19:35, schrieb Bob Tolbert:
One thing that would be nice is support for multiple help screens
(e.g. one per command). For DUB  (or GIT) for example there is one
main help screen that lists all commands along with common options and
then one help screen per command that lists the individual arguments,
options and a summary of what the command does. But maybe for such
more complex CLIs it starts to be more efficient to use a programmatic
if you have a look at the gitD examples, they do just this. If you do
you get the general help for gitD, but if you do
gitD push -h
gitD help push
you get the help for the sub-command "push"
so doing this with 'dub' would be pretty simple.
And you don't have to use external sub-commands either. You can parse
the basic args with the general doc string and then based on the
sub-command chosen, re-parse with the options specific to that sub module.
I haven't looked at the dub source code, but I'd be happy to help sketch
out how this might work there specifically.
Ah OK, nice. I was somehow under the impression that all options would
have to match exactly with what is in the help text. But nesting works
fine like this of course.
As for DUB, it probably doesn't make sense to rewrite the CLI now for no
particular reason. Its command line interface maybe isn't as concise as
a docopt based one, but still does pretty well and also has a few
possible advantages, such as direct type validation and automatic
assembly of help pages with nested options (the help text includes both,
global and command specific options, as well as possible intermediate
level options that are shared among several commands).
Currently, everything is in a single module (the "framework" and all
commands), but that is supposed to be broken up into multiple modules in