Django Local Settings

This is the best practice I think:

• local_settings imports from settings
• local_settings overrides settings specific to the local environment, especially DATABASES, SECRET_KEY, ALLOWED_HOSTS and DEBUG variables
• pass to django management commands the flag --settings=local_settings

You could implement local_settings like this:

from settings import *

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'banco2',                      # Or path to database file if using sqlite3.
        'USER': 'root',                      # Not used with sqlite3.
        'PASSWORD': '123',                  # Not used with sqlite3.
        'HOST': 'localhost',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}

A few additional key points:

• settings.py is in version control, written in a way such that it’s ready to use by contributors
• local_settings.py (or more commonly prod_settings.py) is NOT in version control, and used in production by specifying --settings=prod_settings or similar.

Touching the stock settings file as little as possible also makes it easier to upgrade your django version. When you upgrade Django to the next version, look at the diff in the stock settings.py and yours, and take actions as necessary depending on what changed. Changes in the default values can be important, and the less you touched the original settings.py file, the easier it will be to discern upstream changes.

Since the topic resurfaces routinely let me summarise why you might want to consider this approach:

• a dumb settings file is very fast and easy to change; especially in a production environment. No python required: any idiot can jump in and change the database password in a file which just lists names and values; especially compared to a complex python settings file full of mysterious dangerous BIGCAPS names.

• the application settings should be completely separated from the application code. You can put a config.ini outside the repository root and never again worry about a repo pull clobbering your settings, or your personal settings polluting the repo, or that clever code in your settings.py not making it into the repo to everyone else’s advantage.

This won’t apply to small projects, but on bigger projects I’ve concluded that the local_settings strategy just doesn’t cut it; over time enough application programming creeps in that it gets hard to handle; primarily as settings become derivative and/or codependent. There can be good justifications for settings to react according to the local settings which forces the import of a local_settings file to creep up toward the middle of settings.py. I find things start to get messy as that happens.

My current solution is to use a config file, I dub it “local.ini”. It holds only those values which do actually change between deployed instances. There is no code: they are just values and booleans:

[global]
domain = 127.0.0.1:8000
database_host = 127.0.0.1
database_name = test_database
debug = Yes
google_analytics_id = UA-DEV-1
payments = testing
use_cdn = No

With this in place I can treat the settings.py like any other piece of application code: tweak it, check it in, and deploy it without having to worry about testing against whatever code might be lurking in a local_settings python code. My settings.py is free of race conditions that come up when later settings depend on local settings, and I can switch features on and off writing easy-to-follow linear code. No more hurriedly tweaking the local_settings file when I’ve forgotten to add some new value, and no more daves_local_settings.py and bobs_local_settings.py files creeping into the repository.

from ConfigParser import RawConfigParser
parser = RawConfigParser()

APPLICATION_ROOT = path.abspath(path.dirname(__file__))
parser.readfp(open(path.join(APPLICATION_ROOT, 'local.ini')))

# simple variables
DATABASE_HOST = parser.get('global', 'database_host')
DATABASE_NAME = parser.get('global', 'database_name')

# interdependencies
from version import get_cdn_version
CDN = 'd99phdomw5k72k.cloudfront.net'
if parser.getboolean('global', 'use_cdn'):
    STATIC_URL = '/{}/static/{}/'.format(CDN, get_cdn_version())
else:
    STATIC_URL = '/static/'


# switches
payments = parser.get('global', 'payments')
if payments == 'testing':
    PAYMENT_GATEWAY_ENDPOINT = 'https://api.sandbox.gateway.com'
else:
    PAYMENT_GATEWAY_ENDPOINT = 'https://api.live.gateway.com'

If you encounter a BOFH, like I had on one occasion, he got particularly excited about the ability to stick the local.ini into the /etc directory as /etc/ourapp.ini and so keep the application directory itself a pure repository export. Sure you could do that with a local_settings.py but the last thing he wanted to do was mess with python code. A simple config file he could handle.

Before running the server do

export DJANGO_SETTINGS_MODULE=your_app_name.local_settings

where your_app_name should be replaced by your App’s name.
And don’t forget to do

from settings import *

in your local_settings.py file

I kept a copy of __local_settings.py:

• local_settings.py is being ignored in the version control, but not __local_settings.py
• update README.md to inform the team on how to setup: cp {__,}local_settings.py (which make a copy for their local_settings)

In the past

I used to import those settings.

# settings.py
DATABASE = {...}

try:
    from .local_settings import *
except ImportError:
    pass

now

I just import the settings itself from the local_settings.py.

And with the following command: python manage.py runserver --settings=<proj>.local_settings.

# local_settings.py & __local_settings.py
from .settings import *

DATABASE = {...}

And since, I usually don’t interact with manage.py directly, because some parameters are explicitly necessary for me, (e.g. address:port). Therefore, I put all of those command into my Makefile.

For example, here’s my Makefile:

run:
    python manage.py runserver 0.0.0.0:8000 --settings=<proj>.local_settings

sh:
    python manage.py shell_plus --settings=<proj>.local_settings

dep:
    npm install
    pip install -r requirements.txt

Thus:

make dep
make sh 
make run

Conclusion

Provided that you are not using Makefile as your workflow, then you may use the earlier method, but if you are using makefile, then i believe it is better to be more explicit in your Makefile.

I found the similar solution. This is my configuration for this case:

settings.py:

DEBUG = False

try:
    from local_settings import *

except ImportError:
    pass

if DEBUG is False:
    ALLOWED_HOSTS = ['sth.com']
    DATABASES = {
        ....
    }

local_settings.py:

from settings import *
ALLOWED_HOSTS = ['*']
DEBUG = True
DATABASES = {
    ...
}

Yet another approach is to use python-dotenv and environment variables to customize settings for different environments.

Create the .env file along-side your settings.py:

# .env
SECRET_KEY=your-secret-key
DATABASE_PASSWORD=your-database-password

Add the following code to your settings.py:

# settings.py
from dotenv import load_dotenv
load_dotenv()

# OR, explicitly providing path to '.env'
from pathlib import Path  # python 3.4+
env_path = Path('.') / '.env'
load_dotenv(dotenv_path=env_path)

At this point, parsed keys/values from the .env file are present as environment variables and they can be conveniently accessed via os.getenv():

# settings.py
import os
SECRET_KEY = os.getenv('SECRET_KEY')
DATABASE_PASSWORD = os.getenv('DATABASE_PASSWORD')   

Add this to the end of the file settings.py

try:
    from .local_settings import *
except ImportError:
    pass

And create file local_settings.py with your new settings for example

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'banco2',                      # Or path to database file if using sqlite3.
        'USER': 'root',                      # Not used with sqlite3.
        'PASSWORD': '123',                  # Not used with sqlite3.
        'HOST': 'localhost',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '',                      # Set to empty string for default. Not used with sqlite3.
    }
}