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
Unless I've missed something it seems there is currently no way to differentiate between an explicitly passed value and a default value.
This is problematic for establishing value precedence when dealing with other sources of parameter values (a config file in our case).
We're currently using the default values to detect if a given option was passed on the command line but this is imperfect and leads to the following problem:
@option('--some-option', default=1)
Some other way of specifying option values (e.g. a config file) sets some-option = 2
User calls cli with --some-option 1
Under the above workaround this makes it appear as if the config file value (2) should have precedence even though the user explicitly requested value 1.
The text was updated successfully, but these errors were encountered:
How would you propose we distinguish these? I'm not sure if click should even do this, although the info is probably somewhere in the context or could be handled with an extension.
Unless I've missed something it seems there is currently no way to differentiate between an explicitly passed value and a default value.
This is problematic for establishing value precedence when dealing with other sources of parameter values (a config file in our case).
We're currently using the default values to detect if a given option was passed on the command line but this is imperfect and leads to the following problem:
@option('--some-option', default=1)
some-option = 2
--some-option 1
Under the above workaround this makes it appear as if the config file value (
2
) should have precedence even though the user explicitly requested value1
.The text was updated successfully, but these errors were encountered: