Environment Variable List of Structs

[0xForerunner]

Tracking issue for #597

Support parsing environment variables into a list of structs.

Example

    #[derive(Deserialize, Debug, PartialEq)]
    struct Struct {
        a: Vec<Option<u32>>,
        b: u32,
    }

    #[derive(Deserialize, Debug)]
    struct ListOfStructs {
        list: Vec<Struct>,
    }

    let values = vec![
        ("LIST_0_A_0".to_owned(), "1".to_owned()),
        ("LIST_0_A_2".to_owned(), "2".to_owned()),
        ("LIST_0_B".to_owned(), "3".to_owned()),
        ("LIST_1_A_1".to_owned(), "4".to_owned()),
        ("LIST_1_B".to_owned(), "5".to_owned()),
    ];

    let environment = Environment::default()
        .separator("_")
        .try_parsing(true)
        .source(Some(values.into_iter().collect()));

    let config = Config::builder().add_source(environment).build().unwrap();

    let config: ListOfStructs = config.try_deserialize().unwrap();
    assert_eq!(
        config.list,
        vec![
            Struct {
                a: vec![Some(1), None, Some(2)],
                b: 3
            },
            Struct {
                a: vec![None, Some(4)],
                b: 5
            },
        ]
    );

[epage]

Could you find prior art for array env variables like this? It can help for identifying any lessons learned that are worth applying.

I know Cargo has played with supporting more structured env variables (rust-lang/cargo#7406) but there are complexities there and no one has really been pushing that forward.

[0xForerunner]

This project seems to use a similar approach as I've taken here. I can't really imagine another way of doing it at the moment.

[epage]

git puts the index in a weird spot but they also require a _COUNT variable

From https://git-scm.com/docs/git-config#ENVIRONMENT

GIT_CONFIG_COUNT
GIT_CONFIG_KEY_<n>
GIT_CONFIG_VALUE_<n>

If GIT_CONFIG_COUNT is set to a positive number, all environment pairs GIT_CONFIG_KEY_<n> and GIT_CONFIG_VALUE_<n> up to that number will be added to the process’s runtime configuration. The config pairs are zero-indexed. Any missing key or value is treated as an error. An empty GIT_CONFIG_COUNT is treated the same as GIT_CONFIG_COUNT=0, namely no pairs are processed. These environment variables will override values in configuration files, but will be overridden by any explicit options passed via git -c.

This is useful for cases where you want to spawn multiple git commands with a common configuration but cannot depend on a configuration file, for example when writing scripts.

[0xForerunner]

I'm not sure I grasp why _COUNT should be here, as it can always be inferred.

[0xForerunner]

@epage any other thoughts or suggestions on this implementation? #597

[epage]

I'm a bit uncomfortable ignoring git's precedence without knowing more of why they chose what they did and if it applies.

I would also prefer more input and/or prior art as we would be deciding a policy for applications that would be hard to change in the future. While we can easily just bump our major version, CLIs that use this might not have such an easy time.

[momvart]

Similar issue: #536

[epage]

Looks like they are the same issue, closing in favor of #536.