I hope I don't get downvoted, but I think the OP has a point. Command line arguments will do, and perhaps even be better.
Why are there so many harsh comments about this post?
Don’t use environment variables for configuration
61–70 of 296 posts
Re: Don’t use environment variables for configuration
#62Easy fix (if it's the shared, mutable state which bugs you): * Create one class responsible for ingesting env vars at startup. * Call it from main, and abort early with nice messages if it fails to read something. * Now you have a nice (preferably immutable) class which guarantees the config is in a 'good state', and is self-documenting because it lists all the keys it uses to lookup env vars with.
Agreed - this solution works well, and works nicely with statically typed languages.
Re: Don’t use environment variables for configuration
#63I've endlessly debated with myself about this and have come to the conclusion there isn't really a good solution and the best choice is probably put as much in an actual file as possible.
environment is sort of leaky and non-obvious . at least with a file there is something that is written somewhere that can be inspected and passed as an argument or as an environment variable. The only real positive I see with environment is that children of the process group basically get it for free, but that can be a negative in it of itself as well.
If I have to pick between environment and arguments as configuration, I'd probably prefer arguments since the application would have to explicitly iterate over all the arguments and handle them in some manner, like assign them to some structure or global internal to the program.
Re: Don’t use environment variables for configuration
#64Easy fix (if it's the shared, mutable state which bugs you): * Create one class responsible for ingesting env vars at startup. * Call it from main, and abort early with nice messages if it fails to read something. * Now you have a nice (preferably immutable) class which guarantees the config is in a 'good state', and is self-documenting because it lists all the keys it uses to lookup env vars with.
This is essentially what I do in Rails apps. The only reference to an env var is in an initializer that sets an option in the global rails config structure.
Re: Don’t use environment variables for configuration
#65I disagree with this post so strongly - having spent most of my career installing, configuring, and managing other people’s software. > The answer is that you, the end user, can not now. Every program is free to do its own thing and most do. If you have ever spent ages wondering why the exact same commands work when run from one terminal but not the other, this is probably why. If the same program is behaving differe…
+1 - Document .env but don't get rid of .env!
Re: Don’t use environment variables for configuration
#66I disagree with this post so strongly - having spent most of my career installing, configuring, and managing other people’s software. > The answer is that you, the end user, can not now. Every program is free to do its own thing and most do. If you have ever spent ages wondering why the exact same commands work when run from one terminal but not the other, this is probably why. If the same program is behaving differe…
I feel one good argument against envars is loggers might log them, but Ive never been bitten by that myself.
Chromium with --v=1 will indeed spit out the API keys it's been configured with, and the debug output by default gets logged into a file.
Re: Don’t use environment variables for configuration
#67IMO, the author is writing from the perspective of Meson, a command line build tool used by individuals that takes arguments and caches them in a per-project file, whereas most of the negative replies are commenting from the perspective of sysadmins deploying software into homogeneous servers or Docker containers. Would make be a better program if MAKEFLAGS was not an environment variable? (IDK.) Would Git be a bette…
> Would Git be a better program if the project directory was passed as an argument rather than as inherited state (the cwd)? (IDK.)
Well, it can do both :) `--git-dir=` will let you run git for another project directory
Re: Don’t use environment variables for configuration
#68Okay, so, I don't think the author cares about the situation where your entire system is, like, 1) set env var 2) launch long-running network service 3) never spawn another process inheriting the environment. That's the trivial, happy case. This post is probably more useful if you look at it from the perspective of a system invoking many different processes that come and go, somewhat recursively, likely integrating many independently-developed codebases.
With non-trivial use of environment variables, you're just back to arguing about dynamically-scoped variables vs. lexically-scoped variables (comparing environment variables to lexically-scoped global variables seems besides the point). There are uses for dynamic scope and it keeps getting reinvented, but we know it comes with gotchas and typically prefer lexically-scoped variables.
eg., environment variables are handy because you can pass them to your grandchildren without the direct children needing to know about them. Environment variables are hazardous because you can inadvertently pass environment variables to your children without knowing you inherited them from your parent.
Environment variables can save you from having to teach your program to pass on the correct configuration. Environment variables can damn you when your children rely on them and hence omit facilities to propagate configuration in some nuanced manner. etc.
I'm taken aback by the rancor in our comments. It shouldn't come as a surprise that people developing different kinds of software arrive at different best practices. I'm enjoying this kind of post much more when resolving the cognitive dissonance by trying to understand where the other side is coming from and how the experiences that shaped our respective aesthetic intuition differ.
Re: Don’t use environment variables for configuration
#69Mixed feelings about this. I strongly agree with some, but also feel it's missing the point in a lot of places. Environment vars should of course not be used to configure specific programs. Having an environment variable to specify the args with which to call a program is needless complication. Just pass it as an argument. Use a configuration file to configure the program. Environment variables should (only) be used…
Yeah, we have a service that needs to use a proxy for most calls, but one component mustn't use the proxy, in a way that iirc is not properly captured by a `NO_PROXY` entry. Now the abstraction breaks down and the service has some ugly special-case code. :(
Re: Don’t use environment variables for configuration
#70I hope I don't get downvoted, but I think the OP has a point. Command line arguments will do, and perhaps even be better. Why are there so many harsh comments about this post?
There are a lot of use cases. For example, I have 17 applications running on a system that need a connection string. When I need to change that connection string, I can 1) change 17 config files; 2) change 17 shortcuts containing command-line arguments; 3) change one env variable.