It's less painful if you invert those files. For example, create settings/defaults.py, then in settings/dev.py, import * from defaults and override what you need to. Set DJANGO_SETTINGS_MODULE appropriately. You'll thank me when you're adding dev-only apps, middlewares, etc. and can say INSTALLED_APPS = INSTALLED_APPS + [...].

This so much. You should be setting DJANGO_SETTINGS_MODULE in your uwsgi config or in your virtualenv postactivate for dev.

I already do that. I have a common_settings.py, a dev_settings.py, and a local_settings.py. That's not really the use case I am speaking of.

First, it still makes you put all application config into a single config file (considering that even if you "inherit" settings from a common file, it's 100% equivalent to having one big settings file).

Second, you cannot change these settings in-app. They are hard-coded.

If it's not already supported, it shouldn't be difficult to make a Django process respond to the HUP signal by reloading it's settings. That's how Postgres does it.

Don't do this, do:

* settings/base.py * settings/production.py * settings/local.py

settings/base would have your "common" settings, settings/local.py could be as simple as from .settings.base import

Or better, have a folder called local_settings with an __init__.py empty file in (making it a package) and then just drop your custom settings there

something like this:

http://tech.yipit.com/2011/11/02/django-settings-what-to-do-...