Compose: Feature Request: option to disable reading from .env

Created on 4 Jun 2019  路  10Comments  路  Source: docker/compose

Similar/repeat request to #4642. New/different reason now though. Related to https://github.com/docker/compose/issues/6511.

Other systems use the exact same file .env for parsing and processing environment variables. With the release of 1.24.0, the feature where Compose will no longer accept whitespace in variable names sourced from environment files. This matches the Docker CLI behavior. breaks compatibility with other .env utilities. Although my setup does not use the variables in .env for docker-compose, docker-compose now fails because the .env file does not meet docker-compose's format.

I either have to make the .env file fit docker-compose's format or remove the file.

I propose that you can specify an option to ignore the .env file or specify a different .env file (such as .docker.env) in the docker-compose.yml file so that we can work around projects that are already using the .env file for something else.

kinfeature

Most helpful comment

.env is such a standard outside of docker, allowing docker to dictate to me how I should be using it and given I'm not even using it to configure docker itself I feel its a complete overreach by docker.

Thank you for this feature, I hope it gets merged soon.

All 10 comments

Hi @jonmchan,

Thanks for your report. I would prefer to keep issues in the same place so that we can track them. Could you please add this as a comment to the relevant issue?

I'll close this as a duplicate.

hi @chris-crone , this isn't a duplicate. This is a feature request to disable reading .env file. #4642 issue was closed and it's rational for implementing that feature has already been addressed, so it didn't seem appropriate to reopen that issue. #6511 is just rational to why we need this feature, but it is not dependent or directly related.

I think evaluating this feature request independently - "can we have a config option to disable interpreting .env file?" - would be the proper approach to addressing this feature request.

Thanks for clarifying @jonmchan I'll reopen this.

I started looking into the details for implementing such a feature - the --env-file is the only option to change the .env file location. The docker-compose.yml file is not loaded until after the environment file is read. If we were to implement a feature where the .env location could be changed from docker-compose.yml, we would have to read the docker-compose.yml to peak for the parameter beforehand resulting in either 2 reads to docker-compose.yml or changing the order of loading (which may not be good because the env file needs to be set before reading docker-compose.yml). I think reading docker-compose.yml 2 times would be acceptable, thoughts?

Definitely in favour of being able to disable .env from the docker-compose.yml. I just updated Docker to the latest stable release, and it's broken my development environment because we have a .env file lurking that was never intended for Docker consumption.

.env is such a standard outside of docker, allowing docker to dictate to me how I should be using it and given I'm not even using it to configure docker itself I feel its a complete overreach by docker.

Thank you for this feature, I hope it gets merged soon.

Docker just broke my development environment too. :( As a Python developer I use autoenv extensively so all of my .env files start with:

if [ -d "venv" ]; then
  deactivate > /dev/null 2>&1
  source venv/bin/activate
fi

export FLASK_APP=service:app
... blah, blah, blach, etc.

This allows me to simply cd into a folder and have that Python virtual environment immediately activated.

We need a way to disable this behavior or at a minimum have it give a warning and keep going because my .env file is not meant for docker consumption.

This is massively frustrating team! .env is used by so many applications and now all the docker tooling breaks whenever it tries reading what other tools consider to support full bash syntax.

The change will have made these tools unusable in people's dev environments :(

Everyone please comment on PR https://github.com/docker/compose/pull/6850. I don't think it properly addresses this issue, but I would love to get everyone else's feedback. Thanks!

A work-a-round that is essentially the same as a --skip-env-file flag:

docker-compose --env-file /dev/null
Was this page helpful?
0 / 5 - 0 ratings