Live data from Hacker News

Don’t use environment variables for configuration

nibblestew.blogspot.com

71–80 of 296 posts

Re: Don’t use environment variables for configuration

#71
post #51
post #6

I 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…

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...

Re: Don’t use environment variables for configuration

#73
post #47

IMO, 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…

> a command line build tool used by individuals that takes arguments and caches them in a per-project file That is literally one of the worst ideas I’ve ever heard of. And I’ve heard many bad ideas recently.

What's the alternative? That's how make, cmake, msbuild, ninja,docker, and basically every other build tool I'm aware of works

Re: Don’t use environment variables for configuration

#74
post #29
post #12

Earlier quoted context omitted.

I don't know about https://12factor.net either. But I was assigned a task last year to remove configuration from environment variables (for security reasons). I deployed my work to 'production'.

Well, sure, you shouldn't be putting secrets or other sensitive data in environment variables. But garden-variety configuration is fine to put in env vars. Seems like whoever assigned you this task didn't really know what they were doing.

Oops, I've been putting secrets in environment variables since I can remember. Your comment piqued my curiousity on why this is a bad idea.

Found this:

https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-...

https://security.stackexchange.com/questions/197784/is-it-un...

Re: Don’t use environment variables for configuration

#75
post #61

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?

Env vars are a built-in for key-value command line args. Why introduce some custom convoluted way into your app for kv args instead of this standardised approach.

I can understand why some heavily used cli app would support a custom parameter pattern, eg. for ergonomics, but for majority of apps running as deployed services and not cli apps invoked 100 times a day, I don't see a reason to not use env args.

I can run the following and introduce exactly zero parsing boilerplate into my app or invoking scripts.

    port=12345 color=green ./myapp.py
Also - some apps have to be configured from file, others on the command line. Which parameter parsing library even supports that? Env vars support this out of the box.

Re: Don’t use environment variables for configuration

#76
I 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? Attacking something so well established because of personal reasons feels so wrong from my PoV.

That thing wouldn't be a de-facto standard if it was too bad, right? I think we shouldn't play with the foundation that much.

Re: Don’t use environment variables for configuration

#77
post #24

> An environment variable can only contain a single null-terminated stream of bytes. This is very limiting. The same is true of command-lines and files. Computers can only use bytes.

A files' contents are not effectively smuggled just because halfway through a file a NUL is in it, unlike environment or arguments.

Re: Don’t use environment variables for configuration

#78
post #61

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?

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.

> I can 1) change 17 config files; 2) change 17 shortcuts containing command-line arguments; 3) change one env variable.

This seems like forcing the application to take the burden of your configuration system having shortcomings (like not being able to freely convert from a single source of truth into multiple generated files/command lines/...).

Re: Don’t use environment variables for configuration

#79
post #61

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?

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.

Or change ONE file that contains the connection string.
Post reply on HN