There are several ways to organize your production settings in Django. Of course it's up to you which way to chose.
Some developers like to separate production/test/dev settings in different files. This is quite convenient approach if you don't have to mess with them very often. In this case there is base file
base.py which contains all common settings for all environments.
So assume that our Django project's structure is:
. |-- README.md |-- prj_name/ | |-- settings | | |-- __init__.py | | |-- base.py | | |-- dev.py | | |-- prod.py | | |-- test.py | |-- urls.py | |-- wsgi.py |-- some_app/ ...
In this case in our
wsgi.py we just need to specify path to prod settings, e.g.:
""" WSGI config For more information on this file, see https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/ """ import os os.environ.setdefault("DJANGO_SETTINGS_MODULE", "prj_name.settings.prod") from django.core.wsgi import get_wsgi_application application = get_wsgi_application()
Often people who use this approach separates their requirements files the same way.
Here is an example of such organized project:
DJANGO_SETTINGS_MODULEvariable for the ceratin environment.
This approach is used in deployment on Openshift. If there is an opportunity to specify some environment variable in different environments, it's possible to use in settings and get the right value, for example:
if ON_OPENSHIFT: DEBUG = False else: DEBUG = True
Here is a live example:
The last approach I'll describe here is switching to production settings with the Fabric's help:
In this case some lines in dev settings are replaced with production ones.
All of these approaches are commonly used in Django world. Probably it's better to try all of them before making a decision which is more convenient for your special case.