Deriving environment variable names from structs

[IgnisDa]

figment can automatically get names of expected environment variables. With the following config:

#[derive(Deserialize, Debug, Clone, Serialize)]
pub struct OpenlibraryConfig {
    pub url: String
}

#[derive(Deserialize, Debug, Clone, Serialize)]
pub struct BookConfig {
    pub openlibrary: OpenlibraryConfig
}

#[derive(Deserialize, Debug, Clone)]
pub struct AppConfig {
    #[serde(default)]
    book: BookConfig
}

let conf: AppConfig = Figment::new().merge(Env::raw().split("_")).extract()?;

The above configuration expects BOOK_OPENLIBRARY_URL, without me having to manually annotate it in the struct. Would be nice if confique supported it as well.

[jdx]

frankly I see this as an antipattern. It means I can't search a codebase to find where the env vars are defined

[ModProg]

This could also be made configurable, by having an empty #[config(env)] generate this.

Simple case would be to have #[config(env)] expand to #[config(env = "<field-name-in-uppercase>")].

[IgnisDa]

I ended up going with https://github.com/moonrepo/schematic.

[LukasKalbertodt]

I'm torn on this issue.

I kind of agree with @jdx in that I like these things to be easily searchable. Magic deriving of keys is not great. Additionally, I am in favor of assigning env keys consciously and in my own code, I would usually only make a handful of values set-able via env vars. I personally just don't like managing a complex configuration as env file, e.g. because the format is not well defined (e.g. for lists). So I personally don't see the need for this feature.

On the other hand, when you just specify the field name as env key all the time, it's annoying to repeat yourself and possible to forget updating it if you change it. And the generated "configuration template" does contain the env key. Since I always check the generated template into git (and check via CI that it's up to date), that would give search-ability.

Then again, doing anything more complex than just using the field name for the automatic key would be very involved and require rethinking traits. And just the "" might suffice for some, but not others. And looking at the Env type of figment, I'm not sure I want all the flexibility + complexity in my code base.

But looking at it reveals something else: it simply iterates over all env vars and creates a config from that. In confique, the config itself queries specific keys to build itself. But confique could also go the figment way and provide a Env type that is a Deserializer that a Partial can deserialize from. And that Env could also be configurable in a way. However, that means META doesn't contain guaranteed correct information about the env key anymore and the env attribute is unchecked. Alternatively, one could pass the configured Env to the template generation?

So yep, that's where I'm at. I'm happy for input on the issue, but this comment is definitely also for future-me, whenever I return for another round of working on this.

[jdx]

searching is even more important when using AI agents since grepping the source is how they find where things are defined just like humans. When they need to dig deeper and convert between different cases it just makes things take longer and gives ai a harder time.

Conversely, when ai generates code it's no big deal for it to deal with repetition like this.