let development env override production env

[bekzod]

swapped loadEnv to loadEnvDotEnvironment, it will allow to override production env with development env if it exist

[motdotla]

@bekzod can you describe when this would be useful? I'm not seeing why. In fact, in this scenario something like .env.development would end up overriding .env.

Generally, .env is considered production, and the .env.development and .env.staging are more or less conveniences for local development.

[motdotla]

Closing. Will re-open if discussion opens up.

[maxbeatty]

What is an example of differences between .env and .env.development or .env.staging? Shouldn't every environment be defining their own .env? This feels like it goes against the 12 factor idea of env vars never being grouped together as "environments"

[jessefulton]

IMHO, the .env/.env.* relationship is inverted. Let's assume I am testing multiple configurations from my local machine (production, staging, development, and test), and I need to connect to a different database in my test environment. With the current dotenv, I'd need the following files

.env:
FOO=BAR
FEZ=BAZ

.env.production:

DATABASE_NAME=my_db

.env.staging:

DATABASE_NAME=my_db

.env.qa:

DATABASE_NAME=my_db

.env.development:

DATABASE_NAME=my_db

.env.test:

DATABASE_NAME=my_db_test

Now, if the database name changes, instead of simply changing it in .env and allowing it to propagate to all other environments where it's not overridden, I need to change it in four separate files. The relationship is backwards. Granted this is a contrived example, but this type of thing applies to lots of other things like API Keys, log levels, etc. All environments should inherit from production (the base .env file - I shouldn't need a .env.production file to specify the prod configs.)

[maxbeatty]

Completely understand the pain of managing all of those groups of configurations. I feel like this approach is an anti-pattern for configuring a twelve-factor app:

Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as staging or qa. As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle.

If you need to test all of the configurations for all of your environments locally, I would suggest symlinking these to .env. Each configuration would then be complete for its independent environment and not try to inherit for the sake of repeating yourself. Then when you're ready to deploy, you're more confident in the config.

[jessefulton]

At risk of turning this into a long debate... I'd argue that if you're using dotenv as anything other than a tool to manage environment variables in a developer environment, then you're violating other rules listed in that article. .env files should not be in version control and should not be part of any deployment process. It's simply a tool that injects values into the environment, because managing that by hand in a development environment with multiple projects and configurations would be a nightmare. Check out the readme for the ruby dotenv project (which behaves as expected.)

All that aside, what is the benefit of doing it the current way, as opposed to how bekzod and I are proposing?

[motdotla]

The .env.environment should definitely be available as a feature.

@jessefulton to your point about the relationship being inverted - can you confirm that the ruby version is that way? Looking at the code, I believe it is actually the same as our current implementation. It loads the environment and then overrides with the .env with the hash.merge - https://github.com/bkeepers/dotenv/blob/master/lib/dotenv.rb#L7

[jessefulton]

see my latest comment on #5