Enh Req: Introduce Config metadata for troubleshoot of override/layered values

[andrejusc]

Hi, in many situations when multiple sources of configurations are used - it's beneficial to have ability of Config metadata to tell which value came from which source and became effective/actual at the end of sources processing.

Implementation of this could add extra feature, for example "config-meta" and once used/enabled - later have method like "get_meta" or "dump_meta".

So if let say I have something like such for config construction out of 2 sources:

fn make_config() -> Config {
  let current_env = env::var("ENV").unwrap();
  Config::builder()
      .add_source(File::new("env/service", FileFormat::Yaml))
      .add_source(File::new(("env/service-".to_string() + &current_env).as_str(), FileFormat::Yaml))
      .build()
      .unwrap()
}

and let say one of my YAMLs has such:

debug: false

and another:

debug: true

then that new method "dump_meta" could print something like this:

debug: false <= taken from service.yml
debug: true <= taken as override from service-dev.yml and effective

As I'm yet new to Rust - this is just proposal at this point from my side, which I could try to implement one day if no volunteers.

[matthiasbeyer]

Hi! Thanks for taking the time to file this issue!

What you're describing is definitively a good idea. And it is even a part of my ongoing rewrite of config-rs!
Unfortunately, adding this functionality to the existing config-rs codebase would be a big undertaking and maybe even impossible. That's due to the fact how config-rs currently loads values.

[andrejusc]

Thank you for sharing your next-gen activity. As this repo is also quite young and latest version/tag so far is 0.13.3 - I thought it would be appropriate to raise my above request early in the game, so that could be accommodated once 1.0 will be near ;). Finding myself that various other frameworks for Go/Java also often missing this feature, so maybe we need to make then Rust to shine here and thus make it even more attractive for various new development.

[matthiasbeyer]

I thought it would be appropriate to raise my above request early

Sure! The more insight I can get into how users expect the library to work and what features are required, the better! Thanks again for sharing your thoughts, very much appreciated!

1.0

I don't think I will release 1.0 in the near (or even far) future. I am at least not thinking of my -ng efforts as a path to 1.0, just as a way to streamline the story.

But yes you're right, the efforts are definitively to make the story more shiny and deliver something that is a no-brainer to reach for - basically I think config-rs should be "the clap for configuration" 😉

---

Ninja edit: If you want, you can play with config-rs-ng and see whether the feature is implemented in a way you'd expect (search for ConfigView)! Feel free to open issues on the repository, of course, if you find it lacking in any way! But keep in mind that this (config-rs-ng) is nothing that should be used in production yet!