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?
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)
Often I've seen settings files with something like:
and in
localsettings.py
things like database connections andDEBUG
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
:in
default_localsettings.py
I define a bunch of defaults (DEBUG = True
, use a sqlite database in the same directory asdefault_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.