Option for whether or not System ENV values are overwritten or preserved

[fireproofsocks]

The System.put_env/1 call is pretty heavy-handed. It would be nice to allow an option to control whether values in an .env would overwrite existing ENV values or not. I'm thinking of use cases as straight-forward as this:

An .env has some values like:

LOG_LEVEL=warn
# other values...

and then you want to override a value, so you supply the value in the command, e.g.

LOG_LEVEL=debug iex -S mix
# or
LOG_LEVEL=debug _build/myapp

In both cases, the expectation is that the supplied ENV value would override anything already exported to the system.

Perhaps this option could be made available to the Dotenv.load functions, e.g.

Dotenv.load(".env", overwrite: true)

I think the default behavior would be to not overwrite existing values.

[iloveitaly]

Could you explain the use case behind this? In what scenario would this be helpful to you?

I'm a fan of following the ruby dotenv implementation which assumes that the vars in .env should overwrite any previous values based on the load order of dotenv. This makes intuitive sense to me, but I'm curious to learn more about an alternative take.

[urmastalimaa]

Hi!

I have run into the same issue.
The workaround I have employed is to restore the deployment environment after loading dotenv:

original_env = System.get_env()
Dotenv.load!(".env")
for {name, value} <- original_env, do: System.put_env(name, value)

---

I'm a fan of following the ruby dotenv implementation which assumes that the vars in .env should overwrite any previous values based on the load order of dotenv. This makes intuitive sense to me, but I'm curious to learn more about an alternative take.

I am not sure that is the case, based on bkeepers/dotenv README the original environment is preserved:

By default, it won't overwrite existing environment variables as dotenv assumes the deployment environment has more knowledge about configuration than the application does.