django-configurations

django-configurations eases Django project configuration by relying on the composability of Python classes. It extends the notion of Django’s module based settings loading with well established object oriented programming patterns.

Quickstart

Install django-configurations:

pip install django-configurations

Then subclass the included configurations.Settings class in your project’s settings.py or any other module you’re using to store the settings constants, e.g.:

# mysite/settings.py

from configurations import Settings

class MySiteSettings(Settings):
    DEBUG = True

Set the DJANGO_CONFIGURATION environment variable to the name of the class you just created, e.g. in bash:

export DJANGO_CONFIGURATION=MySiteSettings

and the DJANGO_SETTINGS_MODULE environment variable to the module import path as usual, e.g. in bash:

export DJANGO_SETTINGS_MODULE=mysite.settings

Alternatively supply the --configuration option when using Django management commands along the lines of Django’s default --settings command line option, e.g.:

python manage.py runserver --settings=mysite.settings --configuration=MySiteSettings

To enable Django to use your configuration you now have to modify your manage.py or wsgi.py script to use django-configurations’s versions of the appropriate starter functions, e.g. a typical manage.py using django-configurations would look like this:

#!/usr/bin/env python

import os
import sys

if __name__ == "__main__":
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
    os.environ.setdefault('DJANGO_CONFIGURATION', 'MySiteSettings')

    from configurations.management import execute_from_command_line

    execute_from_command_line(sys.argv)

Notice in line 9 we don’t use the common tool django.core.management.execute_from_command_line but instead configurations.management.execute_from_command_line.

The same applies to your wsgi.py file, e.g.:

import os

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
os.environ.setdefault('DJANGO_CONFIGURATION', 'MySiteSettings')

from configurations.wsgi import get_wsgi_application

application = get_wsgi_application()

Here we don’t use the default django.core.wsgi.get_wsgi_application function but instead configurations.wsgi.get_wsgi_application.

That’s it! You can now use your project with manage.py and your favorite WSGI enabled server.

Wait, what?

django-configurations helps you organize the configuration of your Django project by providing the glue code to bridge between Django’s module based settings system and programming patterns like mixins, facades, factories and adapters that are useful for non-trivial configuration scenarios.

It allows you to use the native abilities of Python inheritance without the side effects of module level namespaces that often lead to the unfortunate use of the from foo import * anti-pattern.

Okay, how does it work?

Any subclass of the configurations.Settings class will automatically use the values of its class and instance attributes (including properties and methods) to set module level variables of the same module – that’s how Django will interface to the django-configurations based settings during startup and also the reason why it requires you to use its own startup functions.

That means when Django starts up django-configurations will have a look at the DJANGO_CONFIGURATION environment variable to figure out which class in the settings module (as defined by the DJANGO_SETTINGS_MODULE environment variable) should be used for the process. It then instantiates the class defined with DJANGO_CONFIGURATION and copies the uppercase attributes to the module level variables.

New in version 0.2.

Alternatively you can use the --configuration command line option that django-configurations adds to all Django management commands. Behind the scenes it will simply set the DJANGO_CONFIGURATION environement variable so this is purely optional and just there to compliment the default --settings option that Django adds if you prefer that instead of setting environment variables.

But isn’t that magic?

Yes, it looks like magic, but it’s also maintainable and non-intrusive. No monkey patching is needed to teach Django how to load settings via django-configurations because it uses Python import hooks (PEP 302) behind the scenes.

Usage patterns

There are various configuration patterns that can be implemented with django-configurations. The most common pattern is to have a base class and various subclasses based on the enviroment they are supposed to be used in, e.g. in production, staging and development.

Server specific settings

For example, imagine you have a base setting class in your settings.py file:

from configurations import Settings

class Base(Settings):
    TIME_ZONE = 'Europe/Berlin'

class Dev(Base):
    DEBUG = True
    TEMPLATE_DEBUG = DEBUG

class Prod(Base):
    TIME_ZONE = 'America/New_York'

You can now set the DJANGO_CONFIGURATION environment variable to one of the class names you’ve defined, e.g. on your production server it should be Prod. In bash that would be:

export DJANGO_SETTINGS_MODULE=mysite.settings
export DJANGO_CONFIGURATION=Prod
python manage.py runserver

Alternatively you can use the --configuration option when using Django management commands along the lines of Django’s default --settings command line option, e.g.:

python manage.py runserver --settings=mysite.settings --configuration=Prod

Global settings defaults

Every configurations.Settings subclass will automatically contain Django’s global settings as class attributes, so you can refer to them when setting other values, e.g.:

from configurations import Settings

class Base(Settings):
    TEMPLATE_CONTEXT_PROCESSORS = \
        Settings.TEMPLATE_CONTEXT_PROCESSORS + (
            'django.core.context_processors.request',
        )

    @property
    def LANGUAGES(self):
        return Settings.LANGUAGES + (('tlh', 'Klingon'),)

Mixins

You might want to apply some configuration values for each and every project you’re working on without having to repeat yourself. Just define a few mixin you re-use multiple times:

class FullPageCaching(object):
    USE_ETAGS = True

Then import that mixin class in your site settings module and use it with a Settings class:

from configurations import Settings

class AcmeProd(Settings, FullPageCaching):
    DEBUG = False
    # ...

Alternatives

Many thanks to those project that have previously solved these problems:

• The Pinax project for spearheading the efforts to extend the Django project metaphor with reusable project templates and a flexible configuration environment.
• django-classbasedsettings by Matthew Tretter for being the immediate inspiration for django-configurations.

Cookbook

Celery

Given Celery’s way to load Django settings in worker processes you should probably just add the following to the begin of your settings module:

from configurations import importer
importer.install()

That has the same effect as using the manage.py or wsgi.py utilities mentioned above.

FastCGI

In case you use FastCGI for deploying Django (you really shouldn’t) and aren’t allowed to us Django’s runfcgi management command (that would automatically handle the setup for your if you’ve followed the quickstart guide above), make sure to use something like the following script:

#!/usr/bin/env python

import os
import sys

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
os.environ.setdefault('DJANGO_CONFIGURATION', 'MySiteSettings')

from configurations.fastcgi import runfastcgi

runfastcgi(method='threaded', daemonize='true')

As you can see django-configurations provides a helper module configurations.fastcgi that handles the setup of your configurations.

Bugs and feature requests

As always you mileage may vary, so please don’t hesitate to send in feature requests and bug reports at the usual place:

https://github.com/jezdez/django-configurations/issues

Thanks!

Changelog

v0.2.1 (2013-04-11)

• Fixed a regression in parsing the new -C/--configuration management command option.
• Minor fix in showing the configuration in the runserver management command output.

v0.2 (2013-03-27)

• backward incompatible change Dropped support for Python 2.5! Please use the 0.1 version if you really want.
• Added Python>3.2 and Django 1.5 support!
• Catch error when getting or evaluating callable setting class attributes.
• Simplified and extended tests.
• Added optional -C/--configuration management command option similar to Django’s --settings option
• Fixed the runserver message about which setting is used to show the correct class.
• Stopped hiding AttributeErrors happening during initialization of settings classes.
• Added FastCGI helper.
• Minor documentation fixes

v0.1 (2012-07-21)

• Initial public release