Wrong choice when multiple values in file about shdotenv

[ko1nksm]

After thinking about it for a while, I think it might be a good idea to do the following.

• By default, environment variables are not overridden by definitions in the env file.
• By default, prohibits definitions with the same name from multiple env files.
• when --overload is specified, environment variables are overwritten with definitions from the env file.
• when --overload is specified, the same name can be defined in multiple env files, with later definitions taking precedence.

[ko1nksm]

Hi, thanks for your feedback.

shdotenv follows the tenets of the twelve-factor app. It is hard to get this right, but I am aiming to follow it anyway.

---

enable --overload by default. because it confusing developers.

Personally, I agree that it is confusing, but it is believed that environment variables should take precedence over .env file. Many dotenv tools work that way. For rationale, see the following from dotenv (ruby).

Why is it not overriding existing ENV variables?

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

---

fix --overload to overload only env file values, not parent env.

Please refer to the following FAQ on dotenv-java (originally from motdotla's dotenv). For compatibility with other dotenv tools, shdotenv has its own implementation, but shares the same concept.

FAQ

Q: Should I deploy a .env to e.g. production?

A: Tenant III of the 12 factor app methodology states "The twelve-factor app stores config in environment variables". Thus, it is not recommended to provide the .env file to such environments. dotenv, however, is super useful in e.g a local development environment as it enables a developer to manage the environment via a file which is more convenient.

Using dotenv in production would be cheating. This type of usage, however is an anti-pattern.

Q: Should I have multiple .env files?

A: No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test. Your config should vary between deploys, and you should not be sharing values between environments.

In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

– The Twelve-Factor App

Q: Should I commit my .env file?

A: No. We strongly recommend against committing your .env file to version control. It should only include environment-specific values such as database passwords or API keys. Your production database should have a different password than your development database.

Q: What happens to environment variables that were already set?

A: dotenv-java will never modify any environment variables that have already been set. In particular, if there is a variable in your .env file which collides with one that already exists in your environment, then that variable will be skipped. This behavior allows you to override all .env configurations with a machine-specific environment, although it is not recommended.

Q: What about variable expansion in .env?

A: We haven't been presented with a compelling use case for expanding variables and believe it leads to env vars that are not "fully orthogonal" as The Twelve-Factor App outlines. Please open an issue if you have a compelling use case.

Note and reference: The FAQs present on motdotla's dotenv node project page are so well done that I've included those that are relevant in the FAQs above.

In my opinion it is bad practice to have the same name defined in the same file. The same name definitions are prohibited in dotenv-linter. See: Duplicated Key.

Furthermore, I believe that defining the same name in another .env file would also violate "fully orthogonal". For these reasons, I believe it is better to prohibit the definition of the same name in one or more env files.

[ko1nksm]

We have changed the behavior to the above and released v0.12.0. We are closing this Issue for now. If you have further comments, please reopen or create another Issue.

[chazer]

It works, awesome!
Good job, thanks for the fix

$ ./shdotenv --version
0.12.0

usage as settings file preferred over environment

$ cat <<EOF > example.env 
SSH_HOST=oldest
SSH_HOST=old
SSH_HOST=actual
EOF

$ SSH_HOST='default' SSH_PORT=22 ./shdotenv -e example.env --overload \
    -- sh -c 'echo "$SSH_HOST:$SSH_PORT";'
actual:22

usage as in app defaults file (no unique names)

$ cat <<EOF > example.env 
SSH_HOST=default
SSH_PORT=22
EOF

$ SSH_HOST='overload' ./shdotenv -e example.env -- sh -c 'echo "$SSH_HOST:$SSH_PORT";'
overload:22