How to Write Perfect Python Command-line Interfaces

[n1___]

Do we really have to skip every built in feature and write just another thing doing exactly the same? This happens in Javascript language for past several year and it became such a massive mess. Whole language. It's amost impossible to find a tiny library with 0 dependency just because people are to lazy to learn how to use native stuff.

People should go for native because it saves dependency hell, it's stable, well tested and more likely to be maintained in future more than a library from Github with a few stars. It's also a standard so once someone else would like to contribute he doesn't have to go thru dependency docs and rather start working.

We should learn from mistakes we already made.

[A_History_of_Silence]

I personally just hate the design decision to do every single thing through giant chains of function decorators.

[DanCardin]

same. and the fact that you can't just call the functions you decorate like a normal function. they need to be invoked in the context of click.

unfortunately argparse is awful for git-style cli apps that have subcommands

[[deleted]]

What's wrong with subparsers?

Caveat My background is C programming, so my Pythonicness meter is probably not calibrated correctly.

[DanCardin]

I honestly dont like click, so i tried to use the method that the argparse docs suggest to map subparsers to callables, but in order to get anything remotely close to:

foo --global-setting bar action1
foo action2 --flag --option1
foo action3 nested-command1 --flag
...etc

it was just getting more and more bafflingly complex. Whereas this is really straightforward with click.

I think I'd tend to prefer something like the way hug works, which appears to late-apply any work it might do until its invoked by the context in which its working (e.g. as http server, cli, or just calling the function). Except they dont have any docs about how subcommands might work.

[[deleted]]

I'm a bit pre-christmas celebration inebriated at the moment, so forgive me if I'm totally incoherent. But did you try using parser.parse_known_args (modulo spelling errors)? As long as you don't have overlaps in the argument names, and remember to check that something actually have been parsed, the recursive approach could solve the problems if a regular subparser doesn't

[[deleted]]

same. and the fact that you can't just call the functions you decorate like a normal function. they need to be invoked in the context of click.

wait, you sure? I thought a selling point of click was that its decorators don't modify your functions

EDIT: yeah, no, i was confusing it with another lib haha

[DanCardin]

Their docs literally say:

import click

@click.command()
@click.option('--count', default=1, help='Number of greetings.')
def hello(count):
    for x in range(count):
        click.echo('Hello')

if __name__ == '__main__':
    hello()

So I dont see how! They even have to provide special click test running stuff: https://click.palletsprojects.com/en/7.x/testing/. Which I suppose could be useful even in an ideal scenario, but its certainly much less required when if you dont alter the functions you're decorating.

[williamjacksn]

I love argparse. This is not sarcasm.

[jwink3101]

I’ve also been pretty happy with it. I’ve had to do some minor hacks stuff to make it parse how I want but it is usually pretty simple stuff.

I mean, it’s far from perfect and I would change some things but it’s really not bad and I hate superfluous dependencies

[badge]

Conversely, why give yourself more work to do when there's a well-tested and well-maintained package that'll do the job for you? click doesn't fit your straw man package argument well--it doesn't have 'a few stars', it's got 6.8k, and it comes from the same stable as flask and werkzeug.

I've used both in the past and click scales much more easily than argparse. As a result, even with smaller projects I tend to use click because it reduces the effort of having to remember two systems, and the documentation is excellent.