kingpin
kingpin copied to clipboard
alecthomas
Potential solution for ignoring unknown flags
A potential solution for ignoring unknown flags. This is something we've run into a need for with automated deployments of updates.
The basics are that if the parser runs into an unknown TokenShort or TokenLong and the option to ignore unknown is set, it advances the context - potentially past a trailing argument to the flag.
This doesn't break any tests (but doesn't add any yet).
I know the idea was closed in #237 but I figured I'd have a go at it and submit a PR for discussion. Thanks!
How would this work with positional arguments, or even flag arguments, though? eg. --foo bar... IIUC --foo will be ignored but bar won't be?
To be clear, I'm not necessarily against this, I just suspect that if this option is enabled then real errors (eg. typos) will be hidden.
What's the use case for this exactly?
So, --foo bar is handled properly, because after recognizing an unknown TokenShort or TokenLong the parser advances past everything until it finds the next TokenShort, TokenLong, or TokenEOL. There may be cases I haven't thought through, however.
I just added a clearer loop to get to the next usable token (short, long, EOL).
This is just for flags, not sub-commands, although it does work properly for flags on those sub-commands.
How does that account for positional arguments? ie. How does it differentiate between a positional argument and an unknown flag value?
What's the use case for this exactly?
Good question - in the past, we've taken out flag-set params in our code, or added future flags to service definitions, and had to do a delicate dance to not have auto-updates to services fail because of unrecognized flags.
It's a problem that we face that may not be wide-spread, but I know from this and other repos it's not an entirely unique problem. I did recognize that it may not be a need for a majority of users, and so made use of this feature strictly opt-in. (Also opt-in so merging this code doesn't break expected behavior.)
How does that account for positional arguments? ie. How does it differentiate between a positional argument and an unknown flag value?
Let me investigate that... I think it handles it properly because positional args aren't TokenShort or TokenLong tokens, but maybe I'm wrong.
I've run into the following case. Consider having a sendmail binary for example, and you wanna replace it with a custom one that can handle some of the flags ignoring others. There can be lots of flags and they can differ from version to version.
