Django dynamic settings infrastructure and best practices

Django settings includes a list of python variables that are used for a plethora of things from database settings to installed apps. Even many of the reusable apps make some开发者_运维技巧 of the settings required.

With a dozens of sites, it is hard to manage the settings of all the projects.

Fortunately settings is just a python module with variables, so you can do any magic to populate the variables you want.

What practices have you followed or you think can be used to separate various related settings into different files?

Apparently, the existing enterprisey practice is that a developer creates a war and the ops department slaps it to the bluefish and takes care of all the database(and such) ops stuff (according to Jacob's email).

What dynamic settings.py can you create that will aid the existing enterprise practices?

---

Often I've seen settings files with something like:

from localsettings import *

and in localsettings.py things like database connections and DEBUG values are defined. localsettings.py is (or may be) different for each deployment environment (dev/staging/production etc), and doesn't live in source control with everything else.

Something I've found helpful lately is putting this in my settings.py:

try:
    from localsettings import *
except ImportError:
    from default_localsettings import *

in default_localsettings.py I define a bunch of defaults (DEBUG = True, use a sqlite database in the same directory as default_localsettings.py etc).

This might not be useful once you've got things set up, but I've found it useful just to be able to check my project out of source control and have it work straightaway using runserver, without having to set anything up.

---

Follow this settings override example to handle dev, staging, and production environments.

http://djangodose.com/articles/2009/09/handling-development-staging-and-production-enviro/

(archived version at Wayback Machine)

---

Personally, I like it to make a module out of settings like

project/
  settings/
    __init__.py
    settings.py
    local.py

The file __init__.py looks like:

from .settings import *
from .local import *

You have adopt the variable BASE_DIR to point to the directory one level higher.

Using this procedure, you don't have to adopt anything else like the import mechanism. Just use from django.conf import settings. All settings in local.py overwrite the ones in settings.py.

However, this possible solution may be combined with the other answers given above.