Changes between Version 19 and Version 20 of SplitSettings


Ignore:
Timestamp:
10/04/2011 03:36:58 PM (4 years ago)
Author:
ches
Comment:

very simple package approach to per-environment settings

Legend:

Unmodified
Added
Removed
Modified
  • SplitSettings

    v19 v20  
    511511}}}
    512512
    513 Of course, you may find that you actually want some of the above settings in {{{common.py}}}. Configure however you need for your situtation.
     513Of course, you may find that you actually want some of the above settings in {{{common.py}}}. Configure however you need for your situation.
     514
     515=== Simple Package Organization for Environments ===
     516
     517[http://chesmart.in I] have used a Python package organization similar to those above for per-environment settings, but much simplified: leaving inheritance to be handled by plain Python modules, without deep-merging dictionary magic. Just be explicit! It's easier to know what {{{production.py}}} configures at a glance without having to go dig into data structures in other files. Having per-developer settings is asking for issues with inconsistent configurations to crop up in deployment environments.
     518
     519{{{
     520#!sh
     521[myapp]$ tree settings
     522settings
     523├── __init__.py
     524├── defaults.py
     525├── dev.py
     526└── production.py
     527}}}
     528
     529The initial {{{settings.py}}} was moved to {{{settings/defaults.py}}}. By default, the settings package will use development configuration, so that local dev Just Works as normal:
     530
     531{{{settings/__init__.py}}}
     532{{{
     533#!python
     534from dev import *
     535}}}
     536
     537{{{settings/dev.py}}}
     538{{{
     539#!python
     540# Load defaults in order to then add/override with dev-only settings
     541from defaults import *
     542
     543DEBUG = True
     544# ... etc.
     545}}}
     546
     547For production (or staging, etc.), just add an appropriate module and set Django's conventional [https://docs.djangoproject.com/en/dev/topics/settings/ DJANGO_SETTINGS_MODULE environment variable] in your deployment setup to load it:
     548
     549{{{settings/production.py}}}
     550{{{
     551#!python
     552# Load defaults in order to then add/override with production-only settings
     553from defaults import *
     554
     555DEBUG = False
     556# ... etc.
     557}}}
     558
     559Wherever appropriate for your deployment (such as an Apache {{{SetEnv}}} directive, include the equivalent of:
     560
     561{{{
     562#!sh
     563$ export DJANGO_SETTINGS_MODULE=myapp.settings.production
     564}}}
     565
     566Using {{{django-admin.py}}} in deployment rather than {{{manage.py}}} should automatically put your app's package on {{{sys.path}}} so that an import path qualified this way will work.
     567
     568If you must use a {{{settings/local.py}}} for some reason, virtualenvwrapper's {{{postactivate/postdeactivate}}} hooks are a good place to set {{{DJANGO_SETTINGS_MODULE}}} to point to it for local development per-project. It's advisable to eliminate as many potential discrepancies between dev and production configuration as possible, though.
Back to Top