Splitting up the settings file

If you use a source control system (CVS, SVN, ...), or want to publish your application on the web,
it may be a good idea to move sensitive or machine/user specific settings like database
passwords and such out of the main settings.py file.

As discussions on the django-developers mailing list have shown everybody has different
requirements and ideas how to do this. This page is meant to collect some of these ideas for future reference.

One thing to keep in mind is that django's config files are pure python.
This gives you the ultimate flexibility to handle configurations the way you think is best.
Or to quote Adrian Holovaty:

We don't need a default solution for this. It's not within the scope
of this project to tell people how they should organize their settings
files. Take that opportunity to showcase your individualism.

If wanted a settings_local.template file can be put under version control with
instructions to copy it over to settings_local.py, change it to suite the environment,
and to never ever commit it to the RCS system.

# Load the production settings that we will overwrite as needed in our user1 settings file.fromprojectname.config.prodimport*
DEBUG =True
DATABASE_NAME ='devdbname'# More development/maching specific settings

Using a list of conf files (Transifex)

​Transifex has adopted a solution using an ordered list of multiple .conf files inside a settings directory. This helps separating the config options, packaging in Linux distributions, and putting the settings files under /etc.

Accessing and modifying existing settings

I (​Antti Kaihola) use the following solution for defining local settings. It provides access to the original settings while defining local settings. Note: this only works if you import from the base settings.py or settings/__init__.py.

Setting Inheritance with Hierarchy

I (​Karim A. Nassar) need to be able to inherit from a base settings file, then for each environment provide overrides. In dev env, we need developer specific settings. The following extends ​Sergey Yushckeyev's solution above.

This script merges settings/common.py, settings/$APP_ENV.py and settings/<developer overrides>.py, in that order.