RETIRED, further work has moved to Debian project infrastructure
Go to file
Carlton Gibson 7cfbe04ab8 Merge pull request #33 from django-compressor/develop
Merge development changes for update on PyPI
2016-04-19 21:17:43 +02:00
appconf Bump Version 2016-04-19 20:59:59 +02:00
docs Update Changelog 2016-04-19 11:33:22 +02:00
tests Add tests checking `override_settings` compat. 2016-03-19 21:20:35 +01:00
.coveragerc Modernize test setup. 2015-02-15 13:48:14 +01:00
.gitignore Modernize test setup. 2015-02-15 13:48:14 +01:00
.travis.yml Remove py35-dj19 from allow_failures 2016-03-20 11:54:52 +01:00
AUTHORS Add myself to AUTHORS 2015-02-15 05:21:29 -06:00
LICENSE Happy new year 2013-01-28 18:46:21 +01:00
MANIFEST.in Added docs to manifest. 2011-08-25 16:52:41 +02:00
README.rst Add Codecov badge 2015-09-16 07:41:42 -07:00
setup.cfg Create universal wheel files. 2015-02-15 13:24:45 +01:00
setup.py remove dependency to six 2015-10-22 02:18:09 +03:30
tox.ini Drop EOL Django versions from Travis 2016-03-19 20:37:26 +01:00

README.rst

django-appconf

Code Coverage

Build Status

A helper class for handling configuration defaults of packaged Django apps gracefully.

Note

This app precedes Django's own AppConfig classes that act as "objects [to] store metadata for an application" inside Django's app loading mechanism. In other words, they solve a related but different use case than django-appconf and can't easily be used as a replacement. The similarity in name is purely coincidental.

Overview

Say you have an app called myapp with a few defaults, which you want to refer to in the app's code without repeating yourself all the time. appconf provides a simple class to implement those defaults. Simply add something like the following code somewhere in your app files:

from appconf import AppConf

class MyAppConf(AppConf):
    SETTING_1 = "one"
    SETTING_2 = (
        "two",
    )

Note

AppConf classes depend on being imported during startup of the Django process. Even though there are multiple modules loaded automatically, only the models modules (usually the models.py file of your app) are guaranteed to be loaded at startup. Therefore it's recommended to put your AppConf subclass(es) there, too.

The settings are initialized with the capitalized app label of where the setting is located at. E.g. if your models.py with the AppConf class is in the myapp package, the prefix of the settings will be MYAPP.

You can override the default prefix by specifying a prefix attribute of an inner Meta class:

from appconf import AppConf

class AcmeAppConf(AppConf):
    SETTING_1 = "one"
    SETTING_2 = (
        "two",
    )

    class Meta:
        prefix = 'acme'

The MyAppConf class will automatically look at Django's global settings to determine if you've overridden it. For example, adding this to your site's settings.py would override SETTING_1 of the above MyAppConf:

ACME_SETTING_1 = "uno"

In case you want to use a different settings object instead of the default 'django.conf.settings', set the holder attribute of the inner Meta class to a dotted import path:

from appconf import AppConf

class MyAppConf(AppConf):
    SETTING_1 = "one"
    SETTING_2 = (
        "two",
    )

    class Meta:
        prefix = 'acme'
        holder = 'acme.conf.settings'

If you ship an AppConf class with your reusable Django app, it's recommended to put it in a conf.py file of your app package and import django.conf.settings in it, too:

from django.conf import settings
from appconf import AppConf

class MyAppConf(AppConf):
    SETTING_1 = "one"
    SETTING_2 = (
        "two",
    )

In the other files of your app you can easily make sure the settings are correctly loaded if you import Django's settings object from that module, e.g. in your app's views.py:

from django.http import HttpResponse
from myapp.conf import settings

def index(request):
    text = 'Setting 1 is: %s' % settings.MYAPP_SETTING_1
    return HttpResponse(text)