Example
Django default project layout creates a single settings.py. This is often useful to split it like this:
myprojectroot/
myproject/
__init__.py
settings/
__init__.py
base.py
dev.py
prod.py
tests.py
This enables you to work with different settings according to whether you are in development, production, tests or whatever.
When moving from the default layout to this layout, the original settings.py becomes settings/base.py. When every other submodule will "subclass" settings/base.py by starting with from .base import *. For instance, here is what settings/dev.py may look like:
# -*- coding: utf-8 -*-
from .base import * # noqa
DEBUG = True
INSTALLED_APPS.extend([
'debug_toolbar',
])
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
INTERNAL_IPS = ['192.168.0.51', '192.168.0.69']
Alternative #1
For django-admin commands to work properly, you will have to set DJANGO_SETTINGS_MODULE environment variable (which defaults to myproject.settings). In development, you will set it to myproject.settings.dev. In production, you will set it to myproject.settings.prod. If you use a virtualenv, best is to set it in your postactivate script:
#!/bin/sh
export PYTHONPATH="/home/me/django_projects/myproject:$VIRTUAL_ENV/lib/python3.4"
export DJANGO_SETTINGS_MODULE="myproject.settings.dev"
If you want to use a settings module that is not pointed by DJANGO_SETTINGS_MODULE for one time, you can use the --settings option of django-admin:
django-admin test --settings=myproject.settings.tests
Alternative #2
If you want to leave DJANGO_SETTINGS_MODULE at its default configuration (myproject.settings), you can simply tell the settings module which configuration to load by placing the import in your __init__.py file.
In the above example, the same result could be achieved by having an __init__.py set to:
from .dev import *
