Storing Configuration in the environment

There are two different ways to store configurations in the environment. One can choose to store a file name in an environment variable, or one can choose to use one environment variable per configuration. Take https://github.com/spf13/viper for example, the BindEnv() and related functions are designed to work with the one env var per configuration approach. The downside is that setting environment variables in the OS is tedious and requires flat/unstructured configurations. When there is only a couple of configurations, this approach is quite easy to use.

The other approach is to look up a configuration file from an environment variable. Viper provides a way to search multiple multiple locations for a configuration file, possibly for the use case of allowing users to override system defaults (e.g., $HOME/.etc/foo.conf to overide /etc/foo.conf). Viper decided to opt for not merging the two files when overriding, but some people prefer the opposing architecture.

My preferences are

  • Load config from a file - config files permits comments
  • Able to specify the config file - either from an environment variable or command line parameter
  • Ability to override some configs throuch CLI or environment variables

PS - A thought occured on the value of writing an interface over 3rd party libraries (like Viper). Creating your wrapper around a 3rd party library allows one to easily replace the library - your code only touches your interface. However, your interface needs to copy every part of the library API you use. At what point does your interfae become unnecessary duplication? Your interface can be a simpler API than the 3rd party library, but to become simpler, it must make additional assumptions - what if those assumptions stops being true? Your interface now evolve in complexity - making it less useful than the external library itself. When do you choose to use your own interface over a 3rd party library directly? I elect to write my own interface as the default, the value in easily changing underlying implementation is great to me.