Feature Request: option to disable reading from .env

[pauldps]

I am using Docker Compose to run a Rails application that has a component to read from the .env file as well (Dotenv: https://github.com/bkeepers/dotenv).

After trying to figure out why my environment variables were getting all messed up whenever I ran the app using Compose, I found out about Compose's ability to automatically read from .env, and realized it was affecting Dotenv's workflow, which ignores variables set by system.

Example:

• .env: VAR=0 (default value)
• .env.development: VAR=1

Expected behavior: VAR == 1

Upon launching the app in development, Dotenv will read from .env.development first and set VAR to 1 (because a system variable is not expected to be set). When it falls back to .env, VAR is already set so it won't be touched. This is how Dotenv's workflow works.

Received behavior: VAR == 0

Compose will have read from .env and set VAR to 0 in the system/container before launching the app. So when Dotenv reads .env.development, it will skip VAR because value will already be set by system.

I could set the development value directly in .env, but then, the same thing would happen in .env.test or any other local environment.

I don't generally use .env for Compose, so I'd like an option to disable this specific magic. Or just remove it, since I can already achieve the exact same thing using env_file, if I need it.

Thanks.

[shin-]

Compose doesn't insert the values from .env inside the containers it launches, so it seems like your issue is elsewhere. Check out our docs page on the different ways environment variables are used by Compose - hopefully it helps you figure out why your app is discovering a different value than the one you expect it to.

[pauldps]

So, from the docs, Compose will only use .env to resolve the docker-compose.yml file?

The way the docs are laid out didn't make it clear to me. When I am reading the docs and get to the .env section, I am already assuming that the file will insert values in containers, as defaults to any variables that other methods may set. But the docs do say it's used to "configure Compose" so it was likely a misunderstanding on my part.

Before understanding this, I was getting different results when I executed my container using run (things work fine) from what I get using up (things fail). So I did some more testing, and found the culprit. I am using Foreman to run the application, and it also has the ability to read from the .env file. So you're right, the issue is elsewhere.

Thanks for the the answer. Closing.

[DamianPereira]

For any future googlers finding this issue because they wanted foreman to stop loading their env files:

The way I found is foreman --env /dev/null or any empty file (it has to exist or foreman will fail. In my case I was loading a special env file for docker with env_file parameter in docker-compose.yml, and it was getting stepped over by the normal non-docker .env file in the repository.