Make source optional behind Cargo features, or abstact them behind a trait and remove them entirely

[djeedai]

Currently it seems that the various sources (env, file, net) of config are all mandatory, and force a long list of mandatory dependencies. It would be great if at least those sources would be behind feature flags, to allow consuming crates/projects to tailor it to their use case without requiring that many dependencies.

But pushing that idea even further, if I look at the crate I think I see 2 separate roles:

1. the core responsibility for this crate is to manage configs, serializing and deserializing them, and managing overriding and priorities among sources;
2. it also attempts to abstract network or filesystem or environment variable access to provide an out-of-the-box experience, but in doing so limits the flexibility and extensibility to those built-in sources and the set of features they support.

It would be much better in my opinion to abstract the sources under a trait that the users can implement as they want, and then just manage a collection of abstract sources, without the need to specialize any of them in this crate. This would delegate the actual process of reading and writing serialized data to other crates, separating the responsibilities, and providing a lot more flexibility and extensibility. I suspect this would also simplify sources management quite a bit, since they'd be manipulated via a common trait.

[matthiasbeyer]

Hi, thanks for opening this issue ❤️ (and writing this comment). I have been thinking a lot about how to go on with the development of this crate lately.

I totally agree. In my opinion, we should even go one step further and re-think the whole crate. I agree that the core responsibility for this crate is the "overwrite" functionality, where one can layer configurations on each other.

I am thinking on how to tackle this specific issue but also the whole idea of re-thinking the crate. I might open a "project" for this crate and start filling it with ideas (one idea per issue) and then see what we can collect and then agree on.