Optional environment file (env_file)

[dorianamouroux]

Hi !

I'm using docker compose for my project.
All my api keys are stored in a local file (ignored by git) and I inject it into my project with env_file in my docker-compose.yml.
Most of those variables are only for production, you can run the project with the file empty.
The problem is, I can't start my container if the file doesn't exist.
It could be a good idea to add a parameter to env_file to make it optional.

Cheers !
Dorian

[sanmai-NL]

What about creating an empty file? A lot less surprising than accepting non-existing environment variable files.

[dorianamouroux]

That's what we do indeed, but I think an empty file is worse than a non-existent file (with a warning)

[et304383]

I too would like support for letting the execution through when an env_file doesn't exist. Some of the tasks in docker-compose are not executed and if the env_file of those non-executed tasks don't exist, who cares? It should not prevent me from moving forward.

It's a pain in the arse!

[akalipetis]

I would also agree on this one, I would propose creating a warning, in a similar way we do if an environment $variable exists in a docker-compose.yaml file, but is not included in the current environment.

I could draft a PR if this is a behaviour we agree upon.

The upsides I see on such an implementation are:

• the actual file is not necessary, meaning that you don't have to create it each time you clone (given that usually .env files are ignored)
• you still get a warning if the file doesn't exist, so you can be aware of times where a file should have been loaded but eventually didn't, for example due to a typo

[Ghazgkull]

Yes please! This would greatly improve the process of adding new env_files. The song-and-dance currently necessary to create dummy env files is annoying (getting a file into the Git repo but then making sure changes aren't tracked).

[nilbus]

@akalipetis That implementation you described sounds perfect to me.

[shin-]

Closing, see #3955 (comment) for rationale.

[collinbarrett]

Can this be reconsidered? Having to touch dummy .env files in a ton of release pipelines adds a ton of overhead.

[idubinets]

I faced the same issues as well and I have to create the dedicated docker compose for the local dev. This is not convenient at all. It found be nice if env_files be optional as @akalipetis suggested

[ppershing]

For me, I am OK with failing if you want to start the service. However, we have many services in one docker-compose and we dont' launch all of them on all of our machines. And this makes it extremely painful because you need to create empty envs everywhere.

[5ay3h]

IMHO there is no reason why env_file of a not used/initiated service will be evaluated - can we make this operation lazy(er)?

Currently all other service's params (image, build's context, volumes, etc) are also treated as suggested (not being evaluated unless used) - why env_file should be different?

@ulyssessouza 🙏?