proposal: re-organize settings inheritance for staging & production

[tobiasmcnulty]

The fact that production settings inherit from staging settings is confusing and easily gets you into a state where you accidentally deploy a staging setting to production because you forgot to remove it in the production settings file.

I'd vote for having both files inherit from the same parent settings, or staging inheriting from production. More often than not, you'll want to disable or tweak certain things active on production (or add extra logging, for example) in the staging environment , rather than the other way around.

[dpoirier]

Maybe have them both inherit from a settings file named "deployed" or "remote"?

[tobiasmcnulty]

Sounds reasonable to me - it would be the gunicorn equivalent of the dev.py settings.

[mlavin]

Related to this I'd like to see more of these settings pushed into the environment (like DB name/user) so that the settings file doesn't need to know the convention used by the Salt configuration. That change along with giving these a common parent would make #103 easier.

[mlavin]

In a more recent project we are taking the following approach to address this. We have removed the staging and production settings in favor of a single live settings. Settings are configured via environment variables. For the DB settings we use https://github.com/kennethreitz/dj-database-url. We do pass the name of the environment in the os.environ so we can have conditional settings blocks. For instance the live settings are used by the Vagrant setup and we disable email sending (write to the console).

[dpoirier]

This sounds good to me.