Open indigoviolet opened 1 year ago
Certainly could be implemented. It is a commonly used behavior in many CLIs. This is already available with ActionYesNo
, but not when an argument is created from a type hint.
Note that adding this feature introduces edge cases which might make the CLI usage worse. If true/false is required, when it is not given, there is always an error including [--bool {true,false}]
and --bool: expected one argument
. Maybe not the best of messages, but mistakes don't lead to executing the process with unintended parameters. However, making the value optional, can lead to silent mistakes. Which is why there is a warning about this in the fire documentation https://github.com/google/python-fire/blob/master/docs/guide.md#boolean-arguments.
For consistency this would need to work with a bool
type, but also for more complex types, e.g. bool | str | None
. The behavior for all possible cases needs to be clearly defined and be intuitive for users.
I guess the store_true
behaviour is the most common in any shell command, I never see any tool asking for a --flag yes
or --flag true
!
I really appreciate it if you could implement this, and in my opinion, only for the bool
type, and keep the existing behaviour for other types.
🚀 Feature request
Currently, while using CLI(), a bool param must be specified on the command line as
--flag true
or--flag yes
. Is it possible to set it up such that--flag
without theyes
ortrue
will still passTrue
into the function?Motivation
I see this commonly tripping up members on my team.
--flag
is a common pattern,store_true
in argparse, supported in python-fire (https://github.com/google/python-fire/blob/master/docs/guide.md#boolean-arguments)Pitch
--flag
should work the same as--flag yes
or--flag true
Alternatives