add support of hashmap in environment variables

[bnjjj]

Hello, I wanted to add support of hashmap inside environment variable. I suggest this kind of syntax: export FOO="{key:value, key2:value2}"

I'm open to any suggestions :)

[softprops]

I'm not familiar with this format. Do you have any examples of storing hashmap data in env var values like this in the wild? If possible I'd like to align with existing conventions

[bnjjj]

Hmm, the only examples I saw they use kind of JSON syntax like: export MY_VALUE="{key: value, key2: value2}". Do you prefer this format ?

[softprops]

What is like to avoid is inventing a new syntax for env variables Can you link me to some example of those tools?

[bnjjj]

In https://github.com/spf13/viper for example they support json syntax but also this kind of syntax:
If I have

struct Cfg {
   test: HashMap<String, String>,
}

You can have some kind of export TEST_KEY="value" and export TEST_KEY2="value2" but I think we can't do in this way for envy. Maybe I'm wrong ?

[bnjjj]

In Javascript they also use JSON syntax as I see on stackoverflow. But TBH I didn't really find a lot of informations about this kind of issue. I think it's not very frequent

[softprops]

I'm wondering if it might be more useful to assume less about the structure of values and just treat structured data as serde::Serialize types.

Env vars place a design constraint that you represent data as flat keys and values. That's what's currently exposed in envy.

For specialized needs I can see a setup as follows

Serialize a special value as a plain string in an env var then in an impl method, use a serde deserializer of your choice to deseriaze additional data from_str. In your case that might be json. In this case envy doesn't need to change and you have maximum flexibility to encode extra structure in what ever format you like.

[softprops]

export TEST_KEY="value" and export TEST_KEY2="value2"

Prefixed var names are supported but carry a different but common convention. They namespace vars targeting an application

[bnjjj]

I fully understand your concerns. And I am partially agree. What disturbing me is the fact that we support Vec and not HashMap and as HashMap is part of the std lib it's common to implement a default Deserialize implementation. The main issue here is that everytime we want to deal with HashMap it means we must create our own custom type to wrap HashMap and be able to implement Deserialize on it.