> Yes, the problem .env files try to solve is having "environment variables" be injectable from a file so that different applications can have different environment variables by default.
replyThis seems like a misunderstanding: The `.env` file should be `source`d into the current shell (environment). The application reads values using whatever mechanism it uses to read these values from the environment. Nothing should be “injected” into the application, i.e. the application should not read `.env` directly.
(Not sure if you were just being loose with your terminology, trying to clarify.)
Does it matter whether the app reads `.env` directly though?
replyMaybe. How does the application unify different environment variables? Those inherited by the shell, those read from .profile, those set in the process that start the application (be that ./run.sh, a nodejs script, systemd etc...).
replyWhy would it want to? I'd say what you're asking for is actually a code smell. An app should not have a bazillion interlocking ways to be configured, unless there's a strong reason for this!
replyIt's not the app, it's the environment variables that have many ways to be configured.
replyFirst couple sentences sounded like AI so I just stopped.
reply