Managing multiple settings.py files

Question

Possible Duplicate:
How to manage local vs production settings in Django?

I have managed to deploy successfully a Django project on Apache's Web Server with mod_wsgi.

I would like some recommendations on how to manage multiple settings.py files. Right now I have one for development and one totally different for production (regarding DB parameters, static content localization, and stuff like that). My settings.py file is versioned (don't know if this is a good practise) and I deploy it with something like:

$ hg archive myproject.tbz2
$ cd /path/of/apache/web/project/location
$ bzip2 -db /home/myself/myproject/myproject.tbz2 | tar -xvf -

It's working OK. But I find myself manipulating multiple settings.py files.

I guess my question is: what are the best practices when deploying DJANGO PROJECTS regarding multiple settings.py file versions?

possible duplicate of [How to manage local vs production settings in Django?](http://stackoverflow.com/questions/1626326/how-to-manage-local-vs-production-settings-in-django) or [Django database settings for production server](http://stackoverflow.com/questions/4887851/django-database-settings-for-production-server) or [Django dynamic settings infrastructure and best practices](http://stackoverflow.com/questions/2109352/django-dynamic-settings-infrastructure-and-best-practices) — Ned Batchelder, Mar 01 '11 at 20:25
Thanks Ned. I would vote to close my own question. The first one you mentioned has the answer I am looking for. Thanks again. — Pablo Santa Cruz, Mar 01 '11 at 20:31

score 29 · Accepted Answer · answered Mar 01 '11 at 22:30

I use a settings module that is not a single file:

settings/
    __init__.py
    _base.py
    _servers.py
    development.py
    production.py
    testing.py

The __init__.py file is simple:

from _servers import get_server_type
exec("from %s import *" % get_server_type())

The _base.py file contains all of the common settings across all server types.

The _servers.py file contains a function get_server_type() that uses socket.gethostname() to determine what type of server the current machine is: it returns development, production or testing.

Then the other files look a bit like (production.py):

DEBUG=False
TEMPLATE_DEBUG=False
from _base import *

In each of these files, I put in the settings that only apply to this server type.

Very clever approach. I am learning a lot with this question. As might have guessed, I am doing my first steps in DJANGO... :-) — Pablo Santa Cruz, Mar 01 '11 at 22:47

score 9 · Answer 2 · answered Mar 01 '11 at 20:41

9

The trick that seems to be the most common is to maintain both a settings.py and local_settings.py (one for each environment) file.

Environment agnostic settings go into settings.py and at the bottom of the file, you'll import from local_settings.py

try:
    from local_settings import *
except ImportError:
    pass

You can override any settings.py settings in the appropriate local_settings.py

answered Mar 01 '11 at 20:41

jboutros

144
4

Awesome tip jboutros. Thanks. Will keep it in mind. – Pablo Santa Cruz Mar 01 '11 at 21:33

score 7 · Answer 3 · edited Mar 02 '16 at 22:24

django-admin.py / manage.py both accept a --settings=mysite.settings option. In development you could explicitly specify --settings=dev_settings. You can also set the DJANGO_SETTINGS_MODULE environment variable in your apache configuration.

Personally, I simply don't check in settings.py. Instead I check in multiple settings files (dev_settings, prod_settings, etc) and symbolically link them to settings.py as desired. This way if I simply checkout my application it won't be runnable until I think about which settings file is appropriate and actually put that settings file in place.

Another suggestion I've heard but I don't particularly like is having a settings.py that dynamically imports a dev_settings.py if it exists. While this may be more convenient I'd be concerned that it's harder to read settings.py and know what the settings will actually be without also looking for overriding values in a dev_settings.py file that may or may not exist.

Thanks Mike. Your answer was really helpful. – Pablo Santa Cruz Mar 01 '11 at 20:35 — Pablo Santa Cruz, Mar 01 '11 at 20:35

score 2 · Answer 4 · answered Mar 01 '11 at 23:42

2

My preferred way is to load a separate ini file using ConfigParser, based off a single setting or environment variable. Anyway in the django wiki there are many different options described: http://code.djangoproject.com/wiki/SplitSettings

answered Mar 01 '11 at 23:42

rewritten

16,280
2
47
50

See also my expanded answer to the question marked as possible duplicate: http://stackoverflow.com/a/9517763/384417 – rewritten Mar 01 '12 at 14:19

Managing multiple settings.py files

4 Answers4

Linked