Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Differentiate between default_value and env in ArgMatches #1345

Closed
drystone opened this issue Sep 25, 2018 · 3 comments · Fixed by #3424
Closed

Differentiate between default_value and env in ArgMatches #1345

drystone opened this issue Sep 25, 2018 · 3 comments · Fixed by #3424
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations E-easy Call for participation: Experience needed to fix: Easy / not much E-help-wanted Call for participation: Help is requested to fix this issue.

Comments

@drystone
Copy link

drystone commented Sep 25, 2018

Maintainer's notes:

Proposed implementation:

  1. Rename ValueType to ArgSource
  2. Add a function to look up the ArgSource

I've a situation where it would be nice to know whether a value has come from a default value or from an environment variable. The workaround is simple but involves rechecking the ArgMatches::value_of against the environment variable.

@swfsql
Copy link

swfsql commented Nov 21, 2018

While still an open issue, I think a viable alternative would be to load values from a configuration file using serde, where no args nor env vars would be involved.

@drystone
Copy link
Author

I'd agree if the value from a configuration file is mandatory. Perhaps, though, it would be nice to have a default so it's not required in the configs?

In order of decreasing precedence a value can come from command line, environment, configuration file, default. If a value is set in the configuration file, a clap match will only override it if it came from the environment, not if it was a default. So it would be nice to be able to differentiate.

@swfsql
Copy link

swfsql commented Nov 21, 2018

I'd agree if the value from a configuration file is mandatory. Perhaps, though, it would be nice to have a default so it's not required in the configs?

Serde does offer #[serde(default)] to use the Default::default() implementation as a fallback, but in this case you'd probably need to move all default values to functions that may be accessed by both Default::default() implementation and clap default_value binding.

But I think this would prevent the avoidance of the default as a fallback from being used, which may be valuable during production, I think.


I agree it'd be nice to fine pick precedence between various inputs.
This crate has some merging operations of structopt/clap and deserialized information, may worth take a look: https://github.com/dalance/structopt-toml

@CreepySkeleton CreepySkeleton added C: args E-help-wanted Call for participation: Help is requested to fix this issue. labels Feb 2, 2020
@CreepySkeleton CreepySkeleton added this to the 3.0 milestone Feb 2, 2020
@pksunkara pksunkara removed the W: 3.x label Aug 13, 2021
@epage epage modified the milestones: 3.0, 3.1 Oct 16, 2021
@pksunkara pksunkara removed this from the 3.1 milestone Oct 16, 2021
@pksunkara pksunkara added this to the 3.1 milestone Oct 26, 2021
@epage epage added A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations E-easy Call for participation: Experience needed to fix: Easy / not much and removed C: args labels Dec 8, 2021
@epage epage removed this from the 3.1 milestone Dec 9, 2021
epage added a commit to epage/clap that referenced this issue Feb 8, 2022
epage added a commit to epage/clap that referenced this issue Feb 8, 2022
epage added a commit to epage/clap that referenced this issue Feb 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parsing Area: Parser's logic and needs it changed somehow. C-enhancement Category: Raise on the bar on expectations E-easy Call for participation: Experience needed to fix: Easy / not much E-help-wanted Call for participation: Help is requested to fix this issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants