3 ms·
> Yes, the problem .env files try to solve is having "environment variables" be injectable from a file so that different applications can have different environ
by jt2190 2mo ago
> 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.
This 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.)
- throw-the-towel 2mo agoDoes it matter whether the app reads `.env` directly though?
- e12e 2mo agoMaybe. 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...).
- throw-the-towel 2mo agoWhy 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!
- sejje 2mo agoIt's not the app, it's the environment variables that have many ways to be configured.
- jt2190 2mo ago> Why would it want to? Because well behaved applications play nice with their host system. I have a strong suspicion that you’re thinking about application configuration, not environment configuration.