Hacker News Reader

Comment by senko | Hacker News Reader

This recommends checking in your (instance-specific) settings to version control. I know some people really push for the opposite (http://www.12factor.net/config, canonical example is Heroku).

Myself, I'm swinging between the two still, haven't found a convincing argument either way.

View on HN

We have canonical settings in our settings.py, while every environment imports local settings from another conf. If it is necessary to have subsidiary settings also source controlled, we could do that and have the environment symlink its preference. Of course, additionally, the secondary settings could have the same dance as the primary settings and allow for another level of local configuration.

  # allow overriding of settings with $HOME/.sodahead
  rc = os.path.join(os.environ["HOME"], ".sodahead")
  if os.path.isfile(rc):
    with open(rc, "r") as fi:
      dotsodahead = imp.load_source("dotsodahead", rc, fi)
      settings = dict([(k, v) for k, v in vars(dotsodahead).items()
          if not k.startswith("__")])
      globals().update(settings)

I agree that apps/modules/libraries should have code separate from configuration. I see no problem with letting configuration be part of a _project_, however. Environment variables are too implicit in a lot of cases, and generally you end up having code checked into some other repository that makes sure the environment variables are set properly. I prefer to skip the middle man and have clearly demarcated sections of configuration directly in my projects.

I'm in the same boat. I whole-heartedly agree that production secret keys, passwords, etc. shouldn't be checked into version control as plain-text.

Even if you use environment variables, you need them stored somewhere (a secrets.py file, a .env file, a upstart script) so they get onto the machine at startup. At the moment we're kicking around GPG encrypting the data and only decrypting it on the machines that need it.

Reply on news.ycombinator.com