Changes between Initial Version and Version 1 of SplitSettings

Timestamp:

Aug 8, 2006, 2:17:15 PM (18 years ago)

Author:

Steven Armstrong

Comment:

--

SplitSettings

@@ +1 @@
+= Splitting up the settings file =
+
+If you use a source control system (CVS, SVN, ...), or want to publish your application on the web, 
+it may be a good idea to move sensitive or machine/user specific settings like database 
+passwords and such out of the main settings.py file. 
+
+As discussions on the django-developers mailing list have shown everybody has different 
+requirements and ideas how to do this. This page is ment to collect some of these ideas for future reference.
+
+One thing to keep in mind is that django's config files are pure python. 
+This gives you the ultimate flexibility to handle configurations the way you think is best.
+Or to quote Adrian Holovaty:
+{{{
+We don't need a default solution for this. It's not within the scope
+of this project to tell people how they should organize their settings
+files. Take that opportunity to showcase your individualism.
+}}}
+
+
+== Different settings in different files ==
+I believe the first user who came up with this was Hugo, who used this method in the projects he published on [https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/ his site].
+
+{{{
+#!python
+
+SECRET_KEY = open(os.path.expanduser('~/.gallery-secret')).read().strip()
+
+}}}
+
+
+== ini-style file for deployment ==
+This is a solution that Michael Radziej posted to django-developers. His motivation was to be able to store the settings
+for an app he published under /etc with all the other system config files.
+
+/etc/whatever/settings.ini
+{{{
+[database]
+DATABASE_USER: bla
+DATABASE_PASSWORD: XXXXXXXX
+DATABASE_HOST: dev
+DATABASE_PORT:
+DATABASE_ENGINE: mysql
+DATABASE_NAME: blo
+TESTSUITE_DATABASE_NAME: test_blo
+
+[secrets]
+SECRET_KEY: random-string-of-ascii
+CSRF_MIDDLEWARE_SECRET: random-string-of-ascii
+
+[cookies]
+SESSION_COOKIE_DOMAIN:
+
+# all settings in debug section should be false in productive
+environment
+# INTERNAL_IPS should be empty in productive environment
+[debug]
+DEBUG: true
+TEMPLATE_DEBUG: true
+VIEW_TEST: true
+INTERNAL_IPS: 127.0.0.1
+SKIP_CSRF_MIDDLEWARE: true
+
+[email]
+SERVER_EMAIL: django@localhost
+EMAIL_HOST: localhost
+
+# the [error mail] and [404 mail] sections are special. Just add
+lines with
+#  full name: email_address@domain.xx
+# each section must be present but may be empty.
+[error mail]
+Adam Smith: adam@localhost
+
+[404 mail]
+John Wayne: john@localhost
+
+}}}
+
+
+/path/to/whatever/settings.py
+{{{
+#!python
+
+from ConfigParser import RawConfigParser
+
+config = RawConfigParser()
+config.read('/etc/whatever/settings.ini')
+
+DATABASE_USER = config.get('database', 'DATABASE_USER')
+DATABASE_PASSWORD = config.get('database', 'DATABASE_PASSWORD')
+DATABASE_HOST = config.get('database', 'DATABASE_HOST')
+DATABASE_PORT = config.get('database', 'DATABASE_PORT')
+DATABASE_ENGINE = config.get('database', 'DATABASE_ENGINE')
+DATABASE_NAME = config.get('database', 'DATABASE_NAME')
+TEST_DATABASE_NAME = config.get('database', 'TESTSUITE_DATABASE_NAME')
+
+SECRET_KEY = config.get('secrets','SECRET_KEY')
+CSRF_MIDDLEWARE_SECRET = config.get('secrets', 'CSRF_MIDDLEWARE_SECRET')
+
+SESSION_COOKIE_DOMAIN = config.get('cookies','SESSION_COOKIE_DOMAIN')
+
+DEBUG = config.getboolean('debug','DEBUG')
+TEMPLATE_DEBUG = config.getboolean('debug','TEMPLATE_DEBUG')
+VIEW_TEST = config.getboolean('debug', 'VIEW_TEST')
+INTERNAL_IPS = tuple(config.get('debug', 'INTERNAL_IPS').split())
+if config.getboolean('debug', 'SKIP_CSRF_MIDDLEWARE'):
+    MIDDLEWARE_CLASSES = tuple([x for x in list(MIDDLEWARE_CLASSES)
+                                  if not x.endswith('CsrfMiddleware')])
+
+SERVER_EMAIL = config.get('email', 'SERVER_EMAIL')
+EMAIL_HOST = config.get('email', 'EMAIL_HOST')
+ADMINS = tuple(config.items('error mail'))
+MANAGERS = tuple(config.items('404 mail'))
+
+}}}
+
+
+== Multiple setting files importing from each other ==
+This is my (Steven Armstrong) preferred solution.
+
+Keep application wide, unsensitive settings and sane defaults in your normal settings.py file.
+
+/path/to/whatever/settings.py
+{{{
+#!python
+import os
+
+BASE_DIR = os.path.dirname(os.path.abspath(__file__))
+#PROJECT_DIR = os.path.abspath(os.path.join(BASE_DIR, '..'))
+PROJECT_DIR = BASE_DIR
+
+DEBUG = False
+TEMPLATE_DEBUG = DEBUG
+
+ADMINS = (
+    ('Mr Sysadmin', 'sysadmin@domain.tld'),
+)
+
+MANAGERS = ADMINS
+
+DATABASE_ENGINE = 'sqlite3'
+DATABASE_NAME = os.path.join(PROJECT_DIR, 'project.db')
+DATABASE_USER = ''
+DATABASE_PASSWORD = ''
+DATABASE_HOST = ''
+DATABASE_PORT = ''
+
+TIME_ZONE = 'Europe/Zurich'
+LANGUAGE_CODE = 'en-us'
+SECRET_KEY = 'secret'
+
+#[more default and app wide settings]
+
+from settings_local import *
+}}}
+
+At the end of your normal settings.py include * from an other, machine specific config file 
+which could look something like this.
+
+/path/to/whatever/settings_local.py
+{{{
+#!python
+
+DEBUG = True
+TEMPLATE_DEBUG = DEBUG
+
+# don't want emails while developing
+ADMINS = ()
+MANAGERS = ADMINS
+
+DATABASE_ENGINE = 'mysql'
+DATABASE_NAME = 'mydbname'
+DATABASE_USER = 'mydbuser'
+DATABASE_PASSWORD = 'mydbpassword'
+DATABASE_HOST = 'localhost'
+DATABASE_PORT = ''
+
+SECRET_KEY = 'random-string-of-ascii'
+
+#[more user/machine specific settings]
+}}}
+
+settings.py goes into CVS, SVN, (put your favorite RCS here)[[BR]]
+settings_local.py does _not_ go under RCS
+
+If wanted a settings_local.template file can be put under version control with
+instructions to copy it over to settings_local.py, change it to suite the environment, 
+and to never ever commit it to the RCS system.