4 ms·

I'm starting to be of the mind that environment variables in general are an anti-pattern. They have arbitrary scope, their lifetime is not clear, and they are n

I'm starting to be of the mind that environment variables in general are an anti-pattern. They have arbitrary scope, their lifetime is not clear, and they are not easily composable. This was not something that bothered me so acutely until I started using declarative config with NixOS to configure my system, and found environment variables to be a big wart on this.

dheera 5y ago
Also, why NO_COLOR? That's "anti". It should be COLOR and set it to true or false.
- chmod775 5y ago
  Possibly because the established default is colored output, and the absence of a boolean environment variable is generally treated as "false". It might also be that COLOR is already used for other purposes by some software.
  - npteljes 5y ago
    Let's call it MONOCHROME then. I too think that "disableSomething=enabled" naming schemes are confusing.
- goodpoint 5y ago
  COLOR=(light|dark|none) would be much better.
- kevincox 5y ago
  This also misses options such as letting COLOR=1 force colours which would be nice when I want to redirect "human" output to a file without bothering to set up a TTY. But I guess that ship has sailed.
Gigachad 5y ago
It’s a real pain when two things use the same name. Spent ages trying to debug an issue and it ended up being the distro I was using was setting “VERSION” which is generic enough that something else happened to be using it as well..
ayushnix 5y ago
Environment variables are fine when used for things that usually don't change once they're set. For example, XDG_CONFIG_HOME or GOPATH. They are, however, absolutely awful when used to configure values that will probably change inside a session. A good example is BEMENU_OPTS from the bemenu program, which is used to change colors, font etc. Should I relogin into my session just to make a program use dark mode colors? https://github.com/Cloudef/bemenu#environment-variables https://github.com/Cloudef/bemenu#environment-variables In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts or overridden on the command line before executing a command, which is extremely annoying.
- oaiey 5y ago
  Is not that the exact same thing as global variables vs constants
- imiric 5y ago
  > In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it. It's no different than setting up an alias, and I'd rather use a wrapper script or alias than have to remember how the app is configured, or search my history for the correct invocation. In fact, environment variables are a very flexible way of configuring an app. They're generic, work the same across apps (no worries about the various ways of specifying flags), avoid the need for a custom configuration file, you can have multiple .env files and load them with env(1), etc. I'm a big fan of following the 12factor[1] approach. [1]: https://12factor.net/config https://12factor.net/config
  - ayushnix 5y ago
    > Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it. I don't know about others but I'm not a fan of monstrosity like this https://github.com/ayushnix/dotfiles/commit/2eb66eff8a03a5bf527b07231151d5b40ee8fd9d#diff-6bc65594897f3748474b8f50643ddf944d44eb992c27b682a24f737a7c0a53d1L37 https://github.com/ayushnix/dotfiles/commit/2eb66eff8a03a5bf... If I stuff it into a wrapper script, I'm essentially trying to emulate config files, which is what should've been used in the first place. This is why I prefer using config files rather than creating uglier and harder to maintain wrapper scripts. > I'm a big fan of following the 12factor[1] approach. I guess if you don't want state associated with your deployments, environment variables are better but I would still argue that they aren't manageable when their values become large as shown above or if their numbers start approaching double digits because when that happens, you're essentially emulating config files anyways.

dheera 5y ago

Also, why NO_COLOR? That's "anti". It should be COLOR and set it to true or false.

chmod775 5y ago
Possibly because the established default is colored output, and the absence of a boolean environment variable is generally treated as "false". It might also be that COLOR is already used for other purposes by some software.
- npteljes 5y ago
  Let's call it MONOCHROME then. I too think that "disableSomething=enabled" naming schemes are confusing.
goodpoint 5y ago
COLOR=(light|dark|none) would be much better.
kevincox 5y ago
This also misses options such as letting COLOR=1 force colours which would be nice when I want to redirect "human" output to a file without bothering to set up a TTY. But I guess that ship has sailed.

Gigachad 5y ago

It’s a real pain when two things use the same name. Spent ages trying to debug an issue and it ended up being the distro I was using was setting “VERSION” which is generic enough that something else happened to be using it as well..

ayushnix 5y ago

Environment variables are fine when used for things that usually don't change once they're set. For example, XDG_CONFIG_HOME or GOPATH. They are, however, absolutely awful when used to configure values that will probably change inside a session. A good example is BEMENU_OPTS from the bemenu program, which is used to change colors, font etc. Should I relogin into my session just to make a program use dark mode colors? https://github.com/Cloudef/bemenu#environment-variables https://github.com/Cloudef/bemenu#environment-variables In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts or overridden on the command line before executing a command, which is extremely annoying.

oaiey 5y ago
Is not that the exact same thing as global variables vs constants
imiric 5y ago
> In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it. It's no different than setting up an alias, and I'd rather use a wrapper script or alias than have to remember how the app is configured, or search my history for the correct invocation. In fact, environment variables are a very flexible way of configuring an app. They're generic, work the same across apps (no worries about the various ways of specifying flags), avoid the need for a custom configuration file, you can have multiple .env files and load them with env(1), etc. I'm a big fan of following the 12factor[1] approach. [1]: https://12factor.net/config https://12factor.net/config
- ayushnix 5y ago
  > Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it. I don't know about others but I'm not a fan of monstrosity like this https://github.com/ayushnix/dotfiles/commit/2eb66eff8a03a5bf527b07231151d5b40ee8fd9d#diff-6bc65594897f3748474b8f50643ddf944d44eb992c27b682a24f737a7c0a53d1L37 https://github.com/ayushnix/dotfiles/commit/2eb66eff8a03a5bf... If I stuff it into a wrapper script, I'm essentially trying to emulate config files, which is what should've been used in the first place. This is why I prefer using config files rather than creating uglier and harder to maintain wrapper scripts. > I'm a big fan of following the 12factor[1] approach. I guess if you don't want state associated with your deployments, environment variables are better but I would still argue that they aren't manageable when their values become large as shown above or if their numbers start approaching double digits because when that happens, you're essentially emulating config files anyways.