I don't have a strong opinion on this, but a comment in the article lead me to this discussion, which is just wild: https://github.com/ninja-build/ninja/issues/1482
I get a sense that the maintainers hold a similar sentiment as the author of this piece, but it's never expressed, but the frustration feels real.
Don’t use environment variables for configuration
121–130 of 296 posts
Re: Don’t use environment variables for configuration
#122Great post! A few months ago I wrote this about my experience with this (mostly based on my experience writing Go):
https://henvic.dev/posts/env/
IMHO almost always (with exceptions) pointing to a secret/value in a file is better. For all other things, flags passed on arguments are better.
Re: Don’t use environment variables for configuration
#123Earlier quoted context omitted.
> This is not what I see in my career. Bulk of the applications we installed and ran used some forms of environment variables for runtime configuration of the tool/application. I think we might have different backgrounds and considerations as to what counts as 'oldschool'? Maybe I shouldn't have extrapolated this to pre-2000... So, my experience comes from working with the following 'mood' of services: Postfix, Exim,…
I've further clarified my PoV here [0], but it won't hurt to reiterate. I'd be happy in fact. > I think we might have different backgrounds and considerations as to what counts as 'oldschool'? Most probably. All of the software you mentioned (maybe except Exim4) is actively used in our environments, quite a few of them are in very vanilla configs, and some of them are customized to the point of abuse. However, it's w…
> I've started with a C64, please. :)
Personal experience in computing is not what I meant. I only realized that I'm not intimately familiar of the dawn of the UNIX daemon and how their configuration methods changed with time, only the echos of this in daily Linux use. Thus, I realized I was possibly extrapolating and assuming things.
> Yes, the tools I've talked about are userspace programs, and are not daemons 99.999% of the time. So you need to run it many times with small differences, and reconfiguring/regenerating file is a lot of work.
Yeah, and I think this lack of distinction is what poisons the discussion surrounding this post - these are separate worlds with different requirements, conflated into a single argument or point of view.
tl;dr I stand by my point with preferring anything over environment variables for services (especially complex ones), but I also fully agree with your usecase for interactive, CLI-driven systems. I mean, one of my favourite programming language features in recent years is that I can cross-compile Go programs just by setting two env vars: GOARCH and GOOS :).
Re: Don’t use environment variables for configuration
#124Author doesn't know about https://12factor.net and as another commenter mentioned, probably hasn't deployed something to a 'production' environment (or rather, doesn't know about separation of such environments in the first place).
Why the trolling? He has valid points. It doesn't matter whether he knows about this methodology or not. Does everything looks like a nail to you?
Re: Don’t use environment variables for configuration
#125I 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?
Unfortunately many people here have a bad attitude thinking they know everything. His point is completely valid. I myself always disliked this kinda recently use of environment variables for configuration – that likely has the 12-factor methodology to blame for its acceptance.
Re: Don’t use environment variables for configuration
#126I never understood why an environment variable makes sense. A type safe configuration in something like Dhall makes much more sense. For secrets environment variables also a terrible idea. An encrypted vault is much better.
Re: Don’t use environment variables for configuration
#127I was taught many moons ago that configuration, like ogres and onions, is best considered in layers: 1. default values: What will most users in most places find most useful/least infuriating? 2. configuration files (system-wide, then user): What will most users on this system want most of the time? What will this particular user want most of the time? 3. environment variables: How should this session (i.e., a potenti…
I like layered config as well. It really should be the default way of thinking about config. Our custom application framework handles that exact sort of layering and it's wonderful. I give it an annotated class representing the config that I need and it handles populating the fields from the config and generating the help message if something is missing.
Re: Don’t use environment variables for configuration
#128Strongly disagree. Environment variables are, IMHO, best tool for some simple configuration in unix. They match perfectly with behavior of the ecosystem and other tools in it (like unix shell). Yes, if your OS is some unversal JS machine, then JSON would be better, if it is Lisp machine, then you would use S-expressions, but on Unix machine, environment/args are way to go. There are two realistic alternatives - confi…
> Perhaps the ideal tool would allow every option to be set/changed from config file, environment and argument.
This is exactly what the most widely used golang configuration library does: https://github.com/spf13/viper
Re: Don’t use environment variables for configuration
#129Earlier quoted context omitted.
What security concerns did that alleviate?
Any third party code in our system can just read whatever's in the environment and POST it to some remote server.
Avoiding environment variables reduces the risk but doesn't eliminate it. The secrets still live in memory in some form, correct? However, it does help to eliminate generic attempts to exfiltrate environment variables.
Tight control of egress network traffic is better but more difficult to implement.
Re: Don’t use environment variables for configuration
#130I have a pet peeve about this attitude. These methods are being used for decades and well understood with all their advantages and disadvantages. One day, someone comes and tells that it's bad and considered harmful , and happily tells the only right way to do it . A flame war ensues then. I'm all for moving things forward and evolution, but can't we take a milder stance and move forward in a more peaceful way? Attac…
> Attacking something so well established because of personal reasons feels so wrong from my PoV.
That is a mischaracterization of the post. The author is making a clear technical point about how environmental variables are global mutable state. Labeling that as an "attack because of personal reasons" is just plain misleading.
> That thing wouldn't be a de-facto standard if it was too bad, right?
How much of the post did you read? Your point is almost exactly the same as the 3rd listed in the post:
> It's the same old trifecta of why things are bad and broken:
> 1. Envvars are easy to add
> 2. There are existing processes that only work via envvars
> 3. "This is the way we have always done it so it must be correct!"