3 ms·

The more applications I write, the more I tend to avoid typical config files in favor of using direnv [0] to set environment variables. [0] https://direnv.net/

The more applications I write, the more I tend to avoid typical config files in favor of using direnv [0] to set environment variables. [0] https://direnv.net/ https://direnv.net/

goku12 3y ago
That's fine as long as there aren't too many variants of configurations. For example, I had a case where multiple ML training runs had to be configured with slight variations in parameters. That too, on the cloud. It can be managed with environment variables - but it becomes messy soon. With TOML, it was just a matter of switching those files around. There are better solutions these days for this particular use-case. However, it should give an idea where environment variables are not a better choice than TOML files.
- omginternets 3y ago
  Agreed, wholeheartedly in fact. My (poorly articulated) point is that the solution is generally to be found in simplifying configuration, rather than in the configuration language itself. This is something that microservice architectures are actually pretty good at doing.
IshKebab 3y ago
Environment variables are awful for config. You get no validation at all - typo in your variable name? It'll just silently ignore it. They can be injected by any parent process and are invisible to all child processes. Also they can be accessed by a simple getenv() anywhere in the program which eventually leads to your config being undocumented and spread all through your code. Environment variables are generally a hack and should be avoided where possible.
- omginternets 3y ago
  I use https://pkg.go.dev/github.com/urfave/cli/v3 https://pkg.go.dev/github.com/urfave/cli/v3 in my Go programs, and it does enough validation that this has never been a problem in practice, especially when paired with a simple config scheme (see my other comment).

3 ms·

The more applications I write, the more I tend to avoid typical config files in favor of using direnv [0] to set environment variables. [0] https://direnv.net/

by omginternets 3y ago

The more applications I write, the more I tend to avoid typical config files in favor of using direnv [0] to set environment variables. [0] https://direnv.net/ https://direnv.net/

goku12 3y ago
That's fine as long as there aren't too many variants of configurations. For example, I had a case where multiple ML training runs had to be configured with slight variations in parameters. That too, on the cloud. It can be managed with environment variables - but it becomes messy soon. With TOML, it was just a matter of switching those files around. There are better solutions these days for this particular use-case. However, it should give an idea where environment variables are not a better choice than TOML files.
- omginternets 3y ago
  Agreed, wholeheartedly in fact. My (poorly articulated) point is that the solution is generally to be found in simplifying configuration, rather than in the configuration language itself. This is something that microservice architectures are actually pretty good at doing.
IshKebab 3y ago
Environment variables are awful for config. You get no validation at all - typo in your variable name? It'll just silently ignore it. They can be injected by any parent process and are invisible to all child processes. Also they can be accessed by a simple getenv() anywhere in the program which eventually leads to your config being undocumented and spread all through your code. Environment variables are generally a hack and should be avoided where possible.
- omginternets 3y ago
  I use https://pkg.go.dev/github.com/urfave/cli/v3 https://pkg.go.dev/github.com/urfave/cli/v3 in my Go programs, and it does enough validation that this has never been a problem in practice, especially when paired with a simple config scheme (see my other comment).