Re-thinking: Config sources

[matthiasbeyer]

We want to support different sources of configuration.

These sources might be "sync" or "async" and should be abstracted via a trait mechanism.

What sources do we want to have?

Some "default" sources might be shipped with the crate:

• Filesystem (sync)
• Filesystem (async with tokio)
• Environment

These sources can be compiletime feature-gated.

What a source should support

A "conifguration value source" should support several things:

• Deserializing into an (internal, common) format
• Updating the already-fetched configuration values
• A human-readable description where the configuration values came from
  • To be able to construct nice error messages if necessary

---

More?

[matthiasbeyer]

I finally found a bit of motivation to work on this.

What I thought of is that providing both sync and async readers from within this crate is likely causing a lot of pain down the road. I'd rather provide building blocks so that users of the crate can build their own readers (sync or async) and provide some default sync ones. For example, reading a string to a config should be easy. If that is easy, reading from a file is easy as well (either sync or async).

[jpmckinney]

reading a string to a config should be easy

Is this already doable, or is it part of #376? (Similarly, reading from a BufRead / BufReader.)

[matthiasbeyer]

This is already possible. It just was written down so we could have a plan! The part that might needs working around is the async part - config-rs is not natively able to work with async config sources... you might need to fiddle a bit for this 😆