You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The motivating use case is to determine whether to override a corresponding piece of configuration or not. Judging from Stack Overflow, it is clear that this has been a thorn in the side of argparse users for years. The most robust solution that I see is to parse twice, once with the "normal" defaults and one with default = argparse.SUPPRESS, and then look at the diff in the arguments namespaces. I don't know how much work this would be to implement in Tyro, but it would allow for simpler CLIs generated by it. Take, for example, a situation that I currently face:
The resulting CLI is awkward in the sense that a user can choose --edit/--no-edit, but if they want to override the configuration for clip, then they must use --clip True or --clip False. (The default clip = None means to defer to configuration.)
where the behavior from tyro.conf.SuppressDefault would be to allow --clip/--no-clip without explicitly specifying the boolean value. If neither --clip nor --no-clip is given by the user, then the default (None) would be the value of the argument. The default would not be displayed as a possible value to the user. This behavior also potentially paves a way to mitigate the enable/disable/retain tristate enum hack that I mentioned in #171.
The text was updated successfully, but these errors were encountered:
The motivating use case is to determine whether to override a corresponding piece of configuration or not. Judging from Stack Overflow, it is clear that this has been a thorn in the side of
argparse
users for years. The most robust solution that I see is to parse twice, once with the "normal" defaults and one withdefault = argparse.SUPPRESS
, and then look at the diff in the arguments namespaces. I don't know how much work this would be to implement in Tyro, but it would allow for simpler CLIs generated by it. Take, for example, a situation that I currently face:The resulting CLI is awkward in the sense that a user can choose
--edit
/--no-edit
, but if they want to override the configuration forclip
, then they must use--clip True
or--clip False
. (The defaultclip = None
means to defer to configuration.)What I would like to do is:
where the behavior from
tyro.conf.SuppressDefault
would be to allow--clip
/--no-clip
without explicitly specifying the boolean value. If neither--clip
nor--no-clip
is given by the user, then the default (None
) would be the value of the argument. The default would not be displayed as a possible value to the user. This behavior also potentially paves a way to mitigate the enable/disable/retain tristate enum hack that I mentioned in #171.The text was updated successfully, but these errors were encountered: