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

Feature - set config values by path #62

Closed
danieleades opened this issue Jan 15, 2023 · 4 comments
Closed

Feature - set config values by path #62

danieleades opened this issue Jan 15, 2023 · 4 comments

Comments

@danieleades
Copy link

i see that it's possible to extract values from configuration using a period-delimited 'path' str. Is there anyway to do the inverse operation? That is, set a nested value using the path to the key.

The use case i'm envisaging is that

  • most of the config for the application will be set in a configuration file, with some nesting
  • a user should be able to override every value in the file if they wish

I had imagined an interface like

APP --config path.to.key=value

what's the best way to approach this using your library?

@Techcable
Copy link

Techcable commented Jan 21, 2023

Ideally, it would be style-preserving too 😄

@SergioBenitez
Copy link
Owner

SergioBenitez commented Jan 23, 2023

That is, set a nested value using the path to the key.

Yes. This is the way string keys work everywhere. See the Serialized provider docs as an example. For instance, (key, value), built using Serialize, works as expected. That is, figment.merge(("a.b", 12)) replaces b in a with 12.

what's the best way to approach this using your library?

Parse the CLI value(s) using something like clap, then simply do something like:

// The value can be anything `Serialize`. `figment::value::Value` is a good choice.
let overrides: Vec<(String, figment::value::Value)> = /* result from CLI parsing */;
let mut figment = /* whatever your figment looks like */;
for override in overrides {
    figment = figment.merge(override);
}

You can even add provenance information to these CLI values by implementing a custom provider, which will give you perfect error messages should something go wrong, but it's not required.

@danieleades
Copy link
Author

ah nice, that's quite powerful. Did I miss this in the docs?

@SergioBenitez
Copy link
Owner

It is documented, though perhaps not as well as it should be. I've added this detail to more places in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants