5 ms·

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

by senko 14y ago

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 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.

ubercore 14y ago
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.
thezilch 14y ago
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)
ipmb 14y ago
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.

by senko 14y ago

ubercore 14y ago

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.

thezilch 14y ago

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)

ipmb 14y ago

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.