> I disagree. Very often, the 'easiest' option wins, not the one that necessarily is the 'best', especially in the long term.
Thank you for your disagreement and discussion, honestly. Actually, I think using environment variables are a burden. Needs more documentation, more explicit warnings, a lot of handling, etc.
So, environment variables are not the easiest way out there. Especially when almost any programming language has nice config file libraries out of the box. Instead these variables are added as a convenience feature for some frequent scenarios where tool needs to adapt itself to the environment it needs to run in, just before starting or needs to be run repeatedly with small, transient changes to the config.
> Furthermore, as long as environments have existed in UNIX and UNIX-like derivatives, their usage to configure the bulk of the behaviour of a service/program are relatively new.
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.
The reason for that the variable had a great deal of effect in the behavior of the program (which was generally scientific) and making multiple runs without modifying a file very effective. You need these runs to conduct research BTW, and you're on a cluster and jobs run long and whatnot.
TBH, most of these applications also had configuration files or "sensible defaults" and they either created their default files if there was none. And if there was a file, the environment variable was acting as an override.
So I had experimental software, fixed most of the parameters in the file and tried some other things by overriding some parameter(s) with an environment variable. Nothing was abused or misused.
> Indeed, sometimes it seems like 90% of the Docker code out there is converting environment variables into configuration files.
I've never seen it TBH, and if that's not documented well, it would be a big bag of fun for the users of that code.
> 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:
All of which have their own config file/files, format, etc. All of these system-wide services, not user applications. And I think that's the main difference? I tend to deal with software that is deployed in isolated environments, be it by root users on production server, or by whoever in a containerized environment. And not deployed on an interactive systems, to then be started/reconfigured by users running on the same system.
> I've never seen it TBH, and if that's not documented well, it would be a big bag of fun for the users of that code.
Check out the list above on Dockerhub. I'm not sure all of them are dockerized in this way, but at least a handful of them are.
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 worth mentioning that all of the software you mentioned are in support roles in our scenario, they're the so-called side dish which we configure once and leave alone for a very long time.
> Maybe I shouldn't have extrapolated this to pre-2000...
I've started with a C64, please. :)
> All of these system-wide services, not user applications. And I think that's the main difference?
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, but as I said, they all have configs and env variables are convenience overrides most of the time.
> Check out the list above on Dockerhub.
Will take a look, thanks. Wanted to learn docker in depth for a long time, but had no notable project to force me to use it. Maybe someday.
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 :).
I'd be absolutely horrified if a service that I use need a specific environment variable set in a particular way to work correctly and it's not well documented. That service would get bonus points for inability to configure that particular option in a configuration file.
I personally would never add environment variables to a program I write which may run as a service.
Thank you for your disagreement and discussion, honestly. Actually, I think using environment variables are a burden. Needs more documentation, more explicit warnings, a lot of handling, etc.
So, environment variables are not the easiest way out there. Especially when almost any programming language has nice config file libraries out of the box. Instead these variables are added as a convenience feature for some frequent scenarios where tool needs to adapt itself to the environment it needs to run in, just before starting or needs to be run repeatedly with small, transient changes to the config.
> Furthermore, as long as environments have existed in UNIX and UNIX-like derivatives, their usage to configure the bulk of the behaviour of a service/program are relatively new.
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.
The reason for that the variable had a great deal of effect in the behavior of the program (which was generally scientific) and making multiple runs without modifying a file very effective. You need these runs to conduct research BTW, and you're on a cluster and jobs run long and whatnot.
TBH, most of these applications also had configuration files or "sensible defaults" and they either created their default files if there was none. And if there was a file, the environment variable was acting as an override.
So I had experimental software, fixed most of the parameters in the file and tried some other things by overriding some parameter(s) with an environment variable. Nothing was abused or misused.
> Indeed, sometimes it seems like 90% of the Docker code out there is converting environment variables into configuration files.
I've never seen it TBH, and if that's not documented well, it would be a big bag of fun for the users of that code.