Question

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?

Answer 1

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.