typed-argparse / typed-argparse

💡 write type-safe and elegant CLIs with a clear separation of concerns.
https://typed-argparse.github.io/typed-argparse/
MIT License
27 stars 6 forks source link

Default sub command #44

Closed Roang-zero1 closed 1 year ago

Roang-zero1 commented 1 year ago

I am currently writing a cli/gui hybrid application with the use of sub commands. Is there a way to implement sub-parsers in a way that marks one of them as default?

I am currently just adding the subcommand to the args via:

args = argv
    if len(args) == 1:
        args.append("gui")
    Parser(...).bind(...).run(args[:1]

But I would realy not add this to potential default sub - sub commands..

bluenote10 commented 1 year ago

That's a good question. Intuitively I feel that sub-parsers with a default may not have sound semantics in general. Imagine some_command has two sub-commands / sub-parsers foo and bar. Now assume that the foo subparser takes one mandatory positional argument, and we make it the default sub-parser. This will result in an ambiguity that cannot be handled in general:

# regular call of subparser foo with positional
some_command foo some_positional_arg

# calling bar
some_command bar

# calling foo via default
some_command some_positional_arg

# but what is this -- is it the positional arg of foo or is it an attempt to call the other sub parser?
some_command bar

Have you tried if plain argparse can do something like that? I'd assume it errors when things get ambiguous.

Roang-zero1 commented 1 year ago

I've tried recreating this with argparse and had to do similar workarounds. The only way I can think of doing this is requiring the default parser to have no positional arguments.

I will close this for now as I think this is something that should be handled on per use case basis.