Cookbook

Calling a Django management command

New in version 0.9.

If you want to call a Django management command programmatically, say from a script outside of your usual Django code, you can use the equivalent of Django’s call_command function with django-configurations, too.

Simply import it from configurations.management instead:

 from configurations.management import call_command

 call_command('dumpdata', exclude=['contenttypes', 'auth'])

Read .env file

Configurations can read values for environment variables out of an .env file, and push them into the application’s process environment. Simply set the DOTENV setting to the appropriate file name:

# mysite/settings.py

import os.path
from configurations import Configuration, values

BASE_DIR = os.path.dirname(os.path.dirname(__file__))

class Dev(Configuration):
    DOTENV = os.path.join(BASE_DIR, '.env')

    SECRET_KEY = values.SecretValue()
    API_KEY1 = values.Value()
    API_KEY2 = values.Value()
    API_KEY3 = values.Value('91011')

A .env file is a .ini-style file. It must contain a list of KEY=value pairs, just like Shell environment variables:

# .env

DJANGO_DEBUG=False
DJANGO_SECRET_KEY=1q2w3e4r5t6z7u8i9o0(%&)$§!pqaycz
API_KEY1=1234
API_KEY2=5678

Envdir

envdir is an effective way to set a large number of environment variables at once during startup of a command. This is great in combination with django-configuration’s Value subclasses when enabling their ability to check environment variables for override values.

Imagine for example you want to set a few environment variables, all you have to do is to create a directory with files that have capitalized names and contain the values you want to set.

Example:

$ tree mysite_env/
mysite_env/
├── DJANGO_SETTINGS_MODULE
├── DJANGO_DEBUG
├── DJANGO_DATABASE_URL
├── DJANGO_CACHE_URL
└── PYTHONSTARTUP

0 directories, 3 files
$ cat mysite_env/DJANGO_CACHE_URL
redis://user@host:port/1
$

Then, to enable the mysite_env environment variables, simply use the envdir command line tool as a prefix for your program, e.g.:

$ envdir mysite_env python manage.py runserver

See envdir documentation for more information, e.g. using envdir from Python instead of from the command line.

Sentry (dynamic setup calls)

For all tools that require an initialization call you should use Setup methods (unless you want them activated for all environments).

Intuitively you might want to add the required setup call like any other setting:

class Prod(Base):
    # ...

    sentry_sdk.init("your dsn", integrations=[DjangoIntegration()])

But this will activate, in this case, Sentry even when you’re running a Dev configuration. What you should do instead, is put that code in the post_setup function. That way Sentry will only ever run when Prod is the selected configuration:

class Prod(Base):
    # ...

    @classmethod
    def post_setup(cls):
        """Sentry initialization"""
        super(Prod, cls).post_setup()
        sentry_sdk.init(
            dsn=os.environ.get("your dsn"), integrations=[DjangoIntegration()]
        )

Project templates

You can use a special Django project template that is a copy of the one included in Django 1.5.x and 1.6.x. The following examples assumes you’re using pip to install packages.

Django 1.8.x

First install Django 1.8.x and django-configurations:

$ pip install -r https://raw.github.com/jazzband/django-configurations/templates/1.8.x/requirements.txt

Or Django 1.8:

$ django-admin.py startproject mysite -v2 --template https://github.com/jazzband/django-configurations/archive/templates/1.8.x.zip

Now you have a default Django 1.8.x project in the mysite directory that uses django-configurations.

See the repository of the template for more information:

Celery

< 3.1

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

import configurations
configurations.setup()

That has the same effect as using the manage.py, wsgi.py or asgi.py utilities. This will also call django.setup().

>= 3.1

In Celery 3.1 and later the integration between Django and Celery has been simplified to use the standard Celery Python API. Django projects using Celery are now advised to add a celery.py file that instantiates an explicit Celery client app.

Here’s how to integrate django-configurations following the example from Celery’s documentation:

 from __future__ import absolute_import

 import os

 from celery import Celery
 from django.conf import settings

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

 import configurations
 configurations.setup()

 app = Celery('mysite')
 app.config_from_object('django.conf:settings')
 app.autodiscover_tasks(lambda: settings.INSTALLED_APPS)

 @app.task(bind=True)
 def debug_task(self):
     print('Request: {0!r}'.format(self.request))

iPython notebooks

New in version 0.6.

To use django-configurations with IPython’s great notebooks, you have to enable an extension in your IPython configuration. See the IPython documentation for how to create and manage your IPython profile correctly.

Here’s a quick how-to in case you don’t have a profile yet. Type in your command line shell:

$ ipython profile create

Then let IPython show you where the configuration file ipython_config.py was created:

$ ipython locate profile

That should print a directory path where you can find the ipython_config.py configuration file. Now open that file and extend the c.InteractiveShellApp.extensions configuration value. It may be commented out from when IPython created the file or it may not exist in the file at all. In either case make sure it’s not a Python comment anymore and reads like this:

# A list of dotted module names of IPython extensions to load.
c.InteractiveShellApp.extensions = [
    # .. your other extensions if available
    'configurations',
]

That will tell IPython to load django-configurations correctly on startup. It also works with django-extensions’s shell_plus management command.

FastCGI

In case you use FastCGI for deploying Django (you really shouldn’t) and aren’t allowed to use 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

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

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.

Sphinx

In case you would like to user the amazing autodoc feature of the documentation tool Sphinx, you need add django-configurations to your extensions config variable and set the environment variable accordingly:

 # My custom Django environment variables
 os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
 os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

 # Add any Sphinx extension module names here, as strings. They can be extensions
 # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
 extensions = [
     'sphinx.ext.autodoc',
     'sphinx.ext.intersphinx',
     'sphinx.ext.viewcode',
     # ...
     'configurations.sphinx',
 ]

 # ...

Changed in version 2.0.

Please note that the sphinx callable has been moved from configurations to configurations.sphinx.

Channels

If you want to deploy a project that uses the Django channels with Daphne as the interface server you have to use a asgi.py script similar to the following:

import os
from configurations import importer
from channels.asgi import get_channel_layer

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "your_project.settings")
os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

importer.install()

channel_layer = get_channel_layer()

That will properly load your django-configurations powered settings.