Support "prefix" for nested struct environment variable names

[brahmlower]

Hey, thanks for the great library!

Has there been any consideration for supporting prefixes on nested structs? It would enable reuse of nested structs in a config like the following:

use std::env;
use envconfig::Envconfig;

#[derive(Envconfig)]
pub struct WebHookConfig {
    #[envconfig(from = "HOOK_URL")]
    url: String,

    #[envconfig(from = "HOOK_TIMEOUT")]
    timeout: i32,
}

#[derive(Envconfig)]
pub struct Config {
    #[envconfig(nested = true, prefix = "CREATE_")]
    create_hook: WebHookConfig,

    #[envconfig(nested = true, prefix = "DELETE_")]
    delete_hook: WebHookConfig,
}

fn main() {
    // We assume that those environment variables are set somewhere outside
    env::set_var("CREATE_HOOK_URL", "example-1.com");
    env::set_var("CREATE_HOOK_TIMEOUT", "8000");
    env::set_var("DELETE_HOOK_URL", "example-2.com");
    env::set_var("DELETE_HOOK_TIMEOUT", "8001");

    // Initialize config from environment variables
    let config = Config::init_from_env().unwrap();

    assert_eq!(config.create_hook.url, "example-1.com");
    assert_eq!(config.create_hook.timeout, 8000);

    assert_eq!(config.delete_hook.url, "example-1.com");
    assert_eq!(config.delete_hook.timeout, 8001);
}

This would be most practical if Option values were supported for nested values (but I figured that might be a conversation for a separate issue?), but still be useful even while Option isn't supported. I'd be happy to put together a PR for this if it's something you think would be a valuable addition to the library 😄

[greyblake]

@brahmlower Hi! Thanks for the warm words and the suggestion.

I'd be happy to put together a PR for this if it's something you think would be a valuable addition to the library
Thanks. That's rare case when I have to discourage you from doing it.. The lib was not updated for a while, and I have gained some better skills with proc macros, so... it's waiting for some refactoring and improvements.

Regarding the example you posted.
I see how it can be useful. I am not like the fact, that the name of env variables is split into 2 chunks this way, so it may be harder to reason about which env vars are used. But at the same time, if I got it right, what you're willing to achieve is to use WebHookConfig more then once.

[brahmlower]

that the name of env variables is split into 2 chunks this way, so it may be harder to reason about which env vars are used

I completely agree with that concern. I figured so long as the feature isn't required for nesting (which it wouldn't be), then the decision for accepting that extra complexity would be left to the consumer of the library.

But at the same time, if I got it right, what you're willing to achieve is to use WebHookConfig more then once.

Yup, you've understood that correctly :)

I actually started trying to implement this feature this past weekend (I was just curious to try), but I realized that this change would require some more significant changes to the way the procedural macros work (or it might not even be possible? I'm not sure). I don't have much experience with procedural macros, so I got kinda stuck.

If you think it's worthwhile to add the feature, we could dig more into the implementation, but if you're hesitant about adding the feature, we can just close out this issue- I'm cool with whichever 👍