RFC-lite: Possible API design & scope

[spacekookie]

This is a small example of how such a crate could work. There are a lot of open questions though.

The baseline for the design of this config crate is however that a user shouldn't have to worry about what platform they're running on and should be designed with the mantra of "Just give me a config" in mind!

(Code Example)

Scope

• Integrate into CLI parsing (clap)?
• Integrate with dotenv?
• Missing features?

Implementation details

• If we use serde for serialize/deserialize, do we have to explicitly declare that?
• Are there any additional options we need to provide to load/create/save?
  • Do we want to provide the app-name differently?
• What config format?
• Is the config format configurable, if so: how?
• Do we want to handle links between configs? Is this important?

And above all: your thoughts?

[killercup]

Sorry it took me two weeks to get back to this :)

The API looks okay. Simple, but we can always add stuff to reduce boilerplate later on (load_or_default, save_or_initialize, …). I'm not sure what this RFC wants to specify, though. CRUD methods for the config files? In general, I'm a bit unsure what confy aims to be right now. We should make a RFC that just adds goals to the Readme :)

So, what I want to have is a crate that basically solves configuration (for CLIs, at least). It should offer a great API to define the structure of you app config, but then only give you one thing: load. Is this confy? And if so, is what you propose here actually the API for a confy-files (sub-)crate that is an adaptor that is internally used by confy?

---

Commenting on the proposed API like it's for a confy-files:

• If we use serde for serialize/deserialize, do we have to explicitly declare that?

Probably. I don't think we can easily add derives from another crate in our derive. (Worth a try, though!)

• Are there any additional options we need to provide to load/create/save?

Delete/cleanup

• What config format?

Rust folks like TOML

• Is the config format configurable, if so: how?

Adding adaptors add support for more things that use serde should be possible. 3rd-party-crates would be cool, otherwise as feature flags.

• Do we want to handle links between configs? Is this important?

No idea. I'd go with "no" for now.

[Dylan-DPC-zz]

Another example by @synek317

[synek317]

@Dylan-DPC actually I'm not sure if it is the right direction. I'm currently working on something between platform-config and config, that is a trait

trait PlatformConfigSource<T> {
    fn get(name: &str) -> T;
}

with two custom derives:

• one for automatically implement PlatformConfigSource
• second one to build from PlatformConfigSource

This way I think provides better separation between app configuration and command line args, more explicitness and less magic. I'm only trying to figure out if there is a way to use current config crate without any modifcations but I think it provides different mechanism - it stores HasMap<String, String> under the hood which I want to avoid

[kamalmarhubi]

Finally looked at this. I'm still curious to see #3 (goals / non-goals) fleshed out some.

[kamalmarhubi]

a derive attr here could remove the need to pass "my_app" below. So something like

#[derive(Confy)]
#[confy(name="my_app")]
strucy MyConfig {
  // ... fields
}

and later, just let cfg: MyConfig = confy::load()? and confy::create(MyConfig { /* ... */ }) etc.

[spacekookie]

@synek317 The entire point of this crate was to create a "magic" solution that people can just drop into their application with very little effort required. The idea of basing it all on some common traits is an interesting one though, essentially allowing easier inter-op between different crates. But for the end-user of confy there should be very little to do and a lot of magic involved...

@kamalmarhubi Good point, we could have a look at what flags people might want to provide and then add them to the proc-macro

[gibix]

In my wishlist I have the need for good config override: global config -> local config -> args -(is_empthy)> default

load_or_default(impl Into<Path>);
load(impl Into<Path>)
    .or(impl Into<Path>)
    .or(struct MyAppConfig);

The support for file parsing should be features-driven like stager?

[spacekookie]

I'm gonna close this PR for now, as the API described in the proposal is almost implemented. I've turned all of the questions/ discussion points into issues so we can talk about the subjects there.

#4 – Multi-part configurations
#5 – Configuration via proc-macro attributs
#6 – CLI argument parsing integration