[BUG] Regressions in .env loading

[jpetazzo]

[BUG] Regressions in .env loading

[ndeloof]

This topic is a never ending issue it seems :'(
Any attempt to "fix" it comes with some users being frustrated by their usage being broken.

As .env file is loaded from "project directory" (base of your compose file) and compose looks for a compose file in the parent folder(s) there's no reason sub/.env would be loaded. But we also allow COMPOSE_FILE to be declared .. by a local .env file, so this one has to be parsed before we actually know project directory - a chicken vs egg problem here. This is the reason sub/.env used to be included in the interpolation, but it never has been documented we "merge" both sub/.env and <project directory>/.env - and obviously some started relying on this 😓

For your scenario, I would recommend to use an explicit --env-file flag to select customer-specific configuration, so you don't rely on this "feature"

[jpetazzo]

I don't understand; it looks like the original behavior (read both .env files and merge) satisfied everyone (by fitting to both use-cases: "I want a global .env at the top-level" and "I want a more specific .env in a subdirectory").

Furthermore, the original behavior did not have the chicken-and-egg problem that you describe, since it was possible to:

1. read the local .env
2. set the COMPOSE_FILE if necessary
3. look for the COMPOSE_FILE, walking up the directory tree if necessary, until it's found
4. read the global .env if it's in a different directory)

Or am I missing something?

The current behavior (read only the top-level .env) does have a chicken-and-egg problem indeed, since the .env might set the COMPOSE_FILE which might make the top-level directory irrelevant. But that problem didn't exist with the original implementation 😅

[ndeloof]

Actually compose v1 only used the local .env file and ignored the one in project directory. This used to bring some issues (as all other paths are relative to project directory) so we changed this, which brings some more issues
Still "load local .env" was required so users can set COMPOSE_ variables - but there's no other reason we should load both env file, until we decide to introduce this as an explicit, documented, tested feature. I agree this covers your usage very well, I just wonder about impacts as this area already suffered many regressions.

[ndeloof]

Also to be mentioned: the logic you describe (read the local .env, then read the global .env if it's in a different directory) won't give you what you expect, as latest read would then set WIN=root, while you're expecting is an environment override. This used to work as the whole local .env was set as os.Env