Closed prjemian closed 2 years ago
At issue here is the fragile assumption:
sub_cmd = sys.argv[1]
Is the purpose of MyArgumentParser
only to avoid typing the full names of the subcommands (for convenience)?
We could instead have tab autocompletion for the subcommands using something like click or argcomplete
That's its purpose. Argument parsing should be robust on any OS. Was not aware of these other packages. How well would they work on Windows with cmd
or PowerShell
?
The issue here raises a hypothetical question for a situation that is not encountered by punx now. Currently, the command-line syntax is one of these:
punx -h
punx -v
punx SUBCOMMAND [OPTION ...] [ARG ...]
The hypothetical asks to be robust if this syntax is added:
punx [OPTION ...] SUBCOMMAND [ARG ...] [OPTION ...]
The feature I'm considering is controlling the log level with an option in that first position. Default level is logging.WARNING
. punx -l
will set level to logging.INFO
, punx -ll
will set level to logging.DEBUG
How well would they work on Windows with cmd or PowerShell?
There's a 3rd party contributor package that extends click shell completing to PowerShell. I have not used this functionality before, so I don't know how easy it is to deploy.
The hypothetical asks to be robust if this syntax is added:
I'm not sure under what circumstances that a user would want to set the logging level without a subcommand. Isn't a subcommand required for all functionality beyond printing the help?
Is there an example of a package you have used which lets you place options before a subcommand?
The conda
package has this, for example. Moving the discussion about alternative parsers and tab completion to #194.
@carterbox : Since there is no definite plan to use this hypothetical syntax, would you agree this issue can be closed as wontfix
?
wontfix
seems fine to me. If you want, you could add a note to the unrecognized arguments message, saying that options for subcommands are expected after the subcommand.
make more robust for variations in optional commands
current assumption is that sys.argv[1] has the subcommand
It is possible to add arguments to the main parser that add optional arguments which may precede a subcommand.