231–240 of 296 posts
To each their own, I suppose.
"Environment variables is exactly this: mutable global state." No it isn't. Every time you start a process, it gets a set of environment variables of its own, which won't be changed by any further changes in the parent process. This is the opposite of how global variables work and is exactly how function arguments work. The rest of the article isn't very good either. The examples of running a program with two differe…
You can attach to a process and call setenv in gdb, so there is a loophole somewhere.
I'm not encouraging this, just pointing out that having a nice binary which reads config, cli, and environment once is still required. Regardless of how you pass that information into your binary.
Easy 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.
import os
ENV_VAR=os.environ.get('ENV_VAR', default_value)
from .config import ENV_VAR
I don't understand how a blog post like this can garner, at time of writing, a hundred upvotes. Normally these types of strong statements "Don't do X/Don't use Y" are attention seeking titles with inversely proportional interestingness of its content. That's the first red flag. The second red flag is that the article is not proof-read: from just the first few minutes of skimming, I found two errors that make the text…
Enviroment variables should be part of cgroups in some way. I dont like that any program can modify the PATH variable as example. seems like a recipe for disaster in privilege escalation.
I don't understand how a blog post like this can garner, at time of writing, a hundred upvotes. Normally these types of strong statements "Don't do X/Don't use Y" are attention seeking titles with inversely proportional interestingness of its content. That's the first red flag. The second red flag is that the article is not proof-read: from just the first few minutes of skimming, I found two errors that make the text…
Of course, that brings its own set of complexity which should be carefully weighed against requirements.
Environment variables are still one of the simplest—and yes, most deterministic ways—to alter behavior of a program.
For server-like applications, env vars denote a _transient_ change in behavior e.g. FLASK_DEBUG=1 python -m flask ... to turn on different behavior in that instance of the application. Persistent configuration changes go to a config file or similar.
For containerized applications, env vars are back to denoting _persistent_ changes in configuration since we bake the values in to deployed containers via whatever orchestrator.
TFA seems to be assailing the first perspective, which is actually reasonable. Sticking secrets and configuration into the shell environment for each tool is not great. Transient config via args and persistent config via files makes lots of sense.
Even in that setting though, there is probably a role for environment variables when spooky-action-at-a-distance changes are required in sub (sub- (sub- ...)) processes / libraries where passing configuration through each caller would be a pain.
I don't understand how a blog post like this can garner, at time of writing, a hundred upvotes. Normally these types of strong statements "Don't do X/Don't use Y" are attention seeking titles with inversely proportional interestingness of its content. That's the first red flag. The second red flag is that the article is not proof-read: from just the first few minutes of skimming, I found two errors that make the text…
Such a shame, Enviroment variables are indeed difficult to work with sometimes, who sets them? in which file? Who can/will override them? typo's are also not being caught because editors dont have lists of possible variable and/or what value they are allowed to contain. you might also lose them on different containers. Enviroment variables should be part of cgroups in some way. I dont like that any program can modify…
The ops team. Environment variables are a great way of separating operational concerns from business logic. Environment variables are great because your application is agnostic about how the configuration is sourced. Let the ops/infra team handle that.
> I dont like that any program can modify the PATH variable as example.
And ... why not? Child processes can't modify the environment of parent processes. Environment variables flow downwards.
Earlier quoted context omitted.
@ajarmst is that last related idea you quoted your own? That’s a powerful expression of how I see human culture: question everything, but remember to respect the ideas of the people who came before you. There might be a baby in the bath water you’re discarding.
It's a restatement of the lesson of Chesterton's Fence. There is a fence somewhere you wish to get rid of. Nobody around knows why it was there in the first place. No one will let you tear it down until somebody figures out why it was put there in the first place. The important take away, is that before changing something, one should understand the history of a thing, or one runs the risk of being a victim of the sam…
Not really; environment variables can't be externally changed once they're passed in. If it were true mutable global state, some external process could change their value while a program is running. Or the program could change the value of the environment variable in the shell that launched it. Either of those would be horrifying.
In other words, environment variables could be worse. They could also be better. My main objection to environment variables is that they're not a discoverable interface. Ideally, it should be possible to find out what environment variables a program accepts without running the program (or grepping the source code for "getenv"), and in most cases it should be possible to enumerate the valid values.
Environment variables are just one of many things about they typical POSIX / ANSI C interface that have been around so long people don't even question it anymore.