Second version-like option

[tdegeus]

I would like to have a second version-like argument (--git) that just prints a hash and quits

myprog
    Lorem ipsum.

Usage:
    myprog [options] <file>

Argument:
    <file>      Some file.

Options:
    -h, --help
        Show help.

    --version
        Show version.

    --git
        Show git commit hash as the time of installation.

How can I do this?

Currently I cannot even do this manually without adding a usage case:

myprog [options]

(which I don't want)

[gsalvatella]

What is the problem with handling it as

if args['--git']:
    print(hash)
    sys.exit(0)

AFAIK only --version and --help are mandatory according to GNU standards. The rest should be manually implemented.

[mentalisttraceur]

The real question is: what good reason do you have for not wanting --git to show up in usage?

--git isn't some almost universal, well-established convention, like --help and --version are.

If I ever use your program, in almost any context or circumstance, I will not even suspect that it takes a --git option.

So then for example if I ever file a bug report, if I knew it took a --git option to print a precise version like a git hash I would proactively put that output in the bug report without being asked because that's obviously useful, but if we waste a round-trip of human interaction before the bug gets looked into because I didn't know about --git so you have to ask me "what's the output of foo --git?" then I will be rather annoyed.

For that matter I don't think it's such a good idea to omit --help and --version from help text.

I think the Usage section definitely should explicitly document the --help and --version options, and the Options section should document their -h and -V (that's a capital V) short aliases. Part of how people learn conventions is by actually seeing it documented repeatedly. New computer users first learning the shell often don't know --version is a big convention for months or even years after they know to try --help. Plus, we should be looking forward to a future of tooling that parses docopt help strings! And exactly how many conventions should that tooling assume are implemented? There's such a simple elegance in just leaving nothing implicit, across the whole stack. And all it costs you is one usage line foo (--help | --version) and a couple options lines.

[mentalisttraceur]

Or maybe you're saying you just don't want it to show up in usage, rather than in the help text at all. Okay, next point:

When I look at

myprog
    Lorem ipsum.

Usage:
    myprog [options] <file>

Argument:
    <file>      Some file.

Options:
    -h, --help
        Show help.

    --version
        Show version.

    --git
        Show git commit hash as the time of installation.

You know what I see? I see that tooling would have no way to tell if myprog --git some-file is a good or bad invocation. And for that matter, neither would any human user who doesn't know very much about Git.

As a human fluent in English, I can read "show git commit hash as the time of installation", almost subconsciously autocorrect it to "as of the time of installation", and as a practicing programmer with Git experience I can deduce that of course --git is a --version-like option, and of course it's not meant to be used as part of normal invocation.

But unless you're writing command line tools for just today's professional/collaborating software developers (as opposed to sys admins, power users, people who are just getting into software, and people who write a bunch of software but still don't know what a "git" is, like many scientists, mathematicians, statisticians, and so on), then that's not going to be obvious to some of your users. And it's definitely not going to be obvious to the kind of tooling we could write to take advantage of help text which follows a standardized format.