This is a voice of reason, not harshness.

One of the projects I currently work on, the configuration system/model/table is a monster.. I wish it was just strings. It basically contains boolean flags, strings, numbers etc but the most insidious one is, it can contain groups of related configs - meaning people started dumping stuff into that should be a normal table (ex, ShippingType:, Road, Rail, Air), so we get no foreign key constraints for reference data. This caused them to implement soft-deletes for it, so now you have some config values that float around forever because they were referenced somewhere (aka pseudo-foreignkey). It's so utterly dumb I want delete the whole thing but everyone thinks it works great (non-tech people). I'm a developer, not a system-admin, but this is too much. Doesn't help that 5 different people has added 'features' to it over the years. The same can be accomplished with something waaaay simpler/cleaner. We also keep having config-related issues where people blame the system/servers/devops etc... every single time it is due to misconfig the project, so the system admins cannot do anything about it anyways (meaning we keep wasting their time, thinking the problem was with the servers). Let me pause here, need to take a blood pressure pill.

> The “best possible syntax” is a universe of possibilities - environment variables are, thankfully, limited to strings.

The same can be said for command line arguments. I usually prefer those instead of environment variables, because they must be explicitly specified instead of being implicitly passed by the parent process. I think of env vars as being more useful when repetitively calling commands interactively, to save some typing, or when you really do want processes to inherit config from parents (like PATH and its variants).

But overall I still agree with your sentiment.

100% this. The developer behind Prometheus was a huge dick to people about env vars a while back, in similar fashion. Just the other day, they held another closed-doors vote after a year or so and finally decided they were OK.

Doesn't surprise me the creator of Meson of all people made the same dogmatic assertion.

What a circus this industry has become.

Any link about that? Are you talking about this? https://github.com/prometheus/prometheus/issues/6047#issueco...

It's fascinating how you can do this job for decades and learn about new tools daily. And I mean tools that are here for ages.

I just learned about envsubst https://www.gnu.org/software/gettext/manual/html_node/envsub...

This was the original discussion that spanned quite a long time. https://github.com/prometheus/prometheus/issues/2357

I came here for this comment. I'm a developer and I have been using env vars for quite some time after I got burned numerous times by other options. I just can't see why I would use anything else.

I have no skin in this game, so to speak, so just curios.

What kind of ways did you get burned by other things than env vars in a way in which env vars would not?

Mostly configuration stored in the database (who configures the database) or 3rd party configuration services without an SLA and config files that are either present or not. Env vars are really simple since they are completely decoupled from the app and you can have default values for all of them. You just need a single class that loads all config on startup and you can go from there (or fail if you don't have the mandatory vars).

>who configures the database

or, what configures the database connection

I forgot the question mark: (who configures the database?). So it is about the problem that if you have your configs in a database then you will carry the additional burden to separately set up databases for each environment....it is like trying to put the hash of an image on the image.

They also work well with serverless environments, containers, etc., which can’t be said for some alternatives.

Environment variables are also more portable and cheaper/simpler than a DBMS, a LDAP service, an application server's proprietary configuration repository, etc. without being weaker at specifying simple configuration values.

In practical terms, specifying environment variables in cleanly isolated and composable layers (defaults by user, a specific terminal session, a script that call another script or the useful program) is a major advantage over more enterprisey and monolithic mechanisms.

Bingo.

The author's title is unfortunate: "Never use environment variables for configuration"

Not everyone is writing CLI scripts. Some are writing multi-environment software for the web. Some people care about git and distributed teams.

Let's say you backup and migrate a db which has config in the db. Well your other environment is using the wrong config! Now you're possibly using prod SMTP credentials and sending notifications to the wrong people because all you wanted to do was have live content and do some testing or show debug messages because you're on a test environment.

Web frameworks which have the HTTP host in the database drive me nuts. Why do you need that? Your webserver is responding on a domain name. Why do some store the absolute url in the db. It makes no sense. For the 3 people that want to serve up domainA.com but have all links readily be domainB.com maybe that makes sense.

Don't get burned people. For most things, just ignore this article, keep your secrets out of version control and keep your code ready to deploy to multiple environments. Decouple that. Your app should be able to work with various configurable services (SMTP, push notifications, database, etc) and you don't want that config in version control.

So either a file that's outside of version control with variables you set per environment or actual server environment variables.

Environment variables in many web languages are just namespaced globals. Still better than global variables. They serve a purpose.

The author has this:

int first_argument;

int second_argument;

void add_numbers(void) { return first_argument + second_argument; }

While it helps the author's agenda, that's not a legitimate example.

A real example would be a service provider which a developer would understand to have the sole purpose of pulling from environment or config values to initialize.

You wanted a Twilio client? Well, we know it needs some keys. Use environment variables. Boom. Everywhere you ask for this Twilio client you get the same instance with the config that that environment needs.

This is not a problem. It works well. Better than any alternative.

Author also says this "Environment variables is exactly this: mutable global state."

For some CLI applications maybe. But for web languages this is not accurate. Some languages, yes, you can mutate the env variables at runtime. But your code shouldn't rely on any mutable env vars. You can load those env vars into a config. Even cache it. Not allow mutations. Many modern frameworks support this or you could implement it yourself.

And if you have a CLI that really needs to be explicit about the environment vars to run? And not be different the next time you call it with no env vars? Well maybe take those as arguments?

Plenty of CLI apps that store config in json and have a wizard to set those credentials. AWS CLI as an example.

Now you got JSON as the author wanted. That can work across platforms. But guess what? You work on multiple clients and hosts and next time you call it? Well you might not be expecting that it had config for another client or app.

Same problem. The state was mutated. You called it again. You potentially got burned. Now you have to do the CLI wizard to reconfigure. Or you pass in explicit params if allowed.

Definitely a consideration if you are writing such a program. Do you make it explicit with arguments and options? Load from ENV vars? Have some CLI wizard and save to JSON?

The author's suggestion of JSON is no reason to toss out ENV vars. Just solves slight differences between Windows and Unix. Which is why you can program a CLI wizard if you care about that problem.

We don't need to say no to env vars because we want CLI app users across different platforms to have the exact same API. Setting up a JSON file is really lame to use a program. Which is why you see cli wizards when you run them.

Or things like "aws configure". And you still have CLI arguments and options availabe.

> If the same program is behaving differently between two systems - it can -only- be the environment that’s different.

Yes, but the entire problem is that "the environment" is massive as it includes all hardware and software running on the device in question (and quite possible other devices as the network can easily be considered part of "the environment") which makes it difficult to track down differing behaviour.

"The environment" is not just environment variables. I've run into a spreadsheet bug where I got wrong results because of a CPU bug. Just because some global mutable state exists, that doesn't mean it's a good software design to have program behaviour depend on it.

>If the same program is behaving differently between two systems - it can -only- be the environment that’s different.

As a developer, I've generally used configuration files for changing the operation of my software and environment variables for information my code needs to know about WHERE the code is running. For example, the same code doing the exact same thing on 10 machines would have the same configuration file (or command line parameters in simpler cases) but the environment variables may change from machine to machine.

I think the post has some merit if we differentiate strongly between what is truly external to the code.

The article's point stands if we're being lame and treating internal code details as external.

> Oh to be a developer. The “best possible syntax” is a universe of possibilities - environment variables are, thankfully, limited to strings. If all programs had to be configured with a Turing complete config language - that would just be a programming language! Limitations can set you free.

I was thinking about this while reading the post. What's the best syntax language or syntax for configuration, if environment variables are too simplistic and full-fledged programming languages are too powerful? That's why I'm interested in Dhall, which is a configuration language that's limited to compile-time only–i.e. it can't do anything at runtime.

There was quite a vogue for using programming languages to configure things for a while. It still has its place I think.

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.