Django Local Settings

You can't just add local_settings.py, you have to explicity import it.

At the very end of your settings.py, add this:

try:    from local_settings import *except ImportError:    pass

The try/except block is there so that Python just ignores the case when you haven't actually defined a local_settings file.

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:8000database_host = 127.0.0.1database_name = test_databasedebug = Yesgoogle_analytics_id = UA-DEV-1payments = testinguse_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 RawConfigParserparser = RawConfigParser()APPLICATION_ROOT = path.abspath(path.dirname(__file__))parser.readfp(open(path.join(APPLICATION_ROOT, 'local.ini')))# simple variablesDATABASE_HOST = parser.get('global', 'database_host')DATABASE_NAME = parser.get('global', 'database_name')# interdependenciesfrom version import get_cdn_versionCDN = 'd99phdomw5k72k.cloudfront.net'if parser.getboolean('global', 'use_cdn'):    STATIC_URL = '/{}/static/{}/'.format(CDN, get_cdn_version())else:    STATIC_URL = '/static/'# switchespayments = 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.