Changes between Version 19 and Version 20 of SplitSettings

Timestamp:

Oct 4, 2011, 3:36:58 PM (14 years ago)

Author:

ches

Comment:

very simple package approach to per-environment settings

SplitSettings

@@ -511 +511 @@
 }}}
 
-Of course, you may find that you actually want some of the above settings in {{{common.py}}}. Configure however you need for your situtation.
+Of course, you may find that you actually want some of the above settings in {{{common.py}}}. Configure however you need for your situation.
+
+=== Simple Package Organization for Environments ===
+
+[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.
+
+{{{
+#!sh
+[myapp]$ tree settings
+settings
+├── __init__.py
+├── defaults.py
+├── dev.py
+└── production.py
+}}}
+
+The 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:
+
+{{{settings/__init__.py}}}
+{{{
+#!python
+from dev import *
+}}}
+
+{{{settings/dev.py}}}
+{{{
+#!python
+# Load defaults in order to then add/override with dev-only settings
+from defaults import *
+
+DEBUG = True
+# ... etc.
+}}}
+
+For 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:
+
+{{{settings/production.py}}}
+{{{
+#!python
+# Load defaults in order to then add/override with production-only settings
+from defaults import *
+
+DEBUG = False
+# ... etc.
+}}}
+
+Wherever appropriate for your deployment (such as an Apache {{{SetEnv}}} directive, include the equivalent of:
+
+{{{
+#!sh
+$ export DJANGO_SETTINGS_MODULE=myapp.settings.production
+}}}
+
+Using {{{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.
+
+If 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.