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.
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
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.