django-appconf
==============
.. image:: http://codecov.io/github/django-compressor/django-appconf/coverage.svg?branch=develop
:alt: Code Coverage
:target: http://codecov.io/github/django-compressor/django-appconf?branch=develop
.. image:: https://secure.travis-ci.org/django-compressor/django-appconf.svg?branch=develop
:alt: Build Status
:target: http://travis-ci.org/django-compressor/django-appconf
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.
.. _AppConfig: https://docs.djangoproject.com/en/stable/ref/applications/#django.apps.AppConfig
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:
.. code-block:: python
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:
.. code-block:: python
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``:
.. code-block:: python
ACME_SETTING_1 = "uno"
Since django-appconf completes Django's global settings with its default values
(like "one" above), the standard ``python manage.py diffsettings`` will show
these defaults automatically.
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:
.. code-block:: python
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:
.. code-block:: python
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``:
.. code-block:: python
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)
Raw data
{
"_id": null,
"home_page": "https://django-appconf.readthedocs.io/",
"name": "django-appconf",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.7",
"maintainer_email": "",
"keywords": "",
"author": "Jannis Leidel",
"author_email": "jannis@leidel.info",
"download_url": "https://files.pythonhosted.org/packages/65/e0/704b6453f21fac22f0ab128150e9782b7d38bc1ed09710ac2197ddc1751f/django-appconf-1.0.6.tar.gz",
"platform": null,
"description": "django-appconf\n==============\n\n.. image:: http://codecov.io/github/django-compressor/django-appconf/coverage.svg?branch=develop\n :alt: Code Coverage\n :target: http://codecov.io/github/django-compressor/django-appconf?branch=develop\n\n.. image:: https://secure.travis-ci.org/django-compressor/django-appconf.svg?branch=develop\n :alt: Build Status\n :target: http://travis-ci.org/django-compressor/django-appconf\n\nA helper class for handling configuration defaults of packaged Django\napps gracefully.\n\n.. note::\n\n This app precedes Django's own AppConfig_ classes that act as\n \"objects [to] store metadata for an application\" inside Django's\n app loading mechanism. In other words, they solve a related but\n different use case than django-appconf and can't easily be used\n as a replacement. The similarity in name is purely coincidental.\n\n.. _AppConfig: https://docs.djangoproject.com/en/stable/ref/applications/#django.apps.AppConfig\n\nOverview\n--------\n\nSay you have an app called ``myapp`` with a few defaults, which you want\nto refer to in the app's code without repeating yourself all the time.\n``appconf`` provides a simple class to implement those defaults. Simply add\nsomething like the following code somewhere in your app files:\n\n.. code-block:: python\n\n from appconf import AppConf\n\n class MyAppConf(AppConf):\n SETTING_1 = \"one\"\n SETTING_2 = (\n \"two\",\n )\n\n.. note::\n\n ``AppConf`` classes depend on being imported during startup of the Django\n process. Even though there are multiple modules loaded automatically,\n only the ``models`` modules (usually the ``models.py`` file of your\n app) are guaranteed to be loaded at startup. Therefore it's recommended\n to put your ``AppConf`` subclass(es) there, too.\n\nThe settings are initialized with the capitalized app label of where the\nsetting is located at. E.g. if your ``models.py`` with the ``AppConf`` class\nis in the ``myapp`` package, the prefix of the settings will be ``MYAPP``.\n\nYou can override the default prefix by specifying a ``prefix`` attribute of\nan inner ``Meta`` class:\n\n.. code-block:: python\n\n from appconf import AppConf\n\n class AcmeAppConf(AppConf):\n SETTING_1 = \"one\"\n SETTING_2 = (\n \"two\",\n )\n\n class Meta:\n prefix = 'acme'\n\nThe ``MyAppConf`` class will automatically look at Django's global settings\nto determine if you've overridden it. For example, adding this to your site's\n``settings.py`` would override ``SETTING_1`` of the above ``MyAppConf``:\n\n.. code-block:: python\n\n ACME_SETTING_1 = \"uno\"\n \nSince django-appconf completes Django's global settings with its default values \n(like \"one\" above), the standard ``python manage.py diffsettings`` will show \nthese defaults automatically.\n\nIn case you want to use a different settings object instead of the default\n``'django.conf.settings'``, set the ``holder`` attribute of the inner\n``Meta`` class to a dotted import path:\n\n.. code-block:: python\n\n from appconf import AppConf\n\n class MyAppConf(AppConf):\n SETTING_1 = \"one\"\n SETTING_2 = (\n \"two\",\n )\n\n class Meta:\n prefix = 'acme'\n holder = 'acme.conf.settings'\n\nIf you ship an ``AppConf`` class with your reusable Django app, it's\nrecommended to put it in a ``conf.py`` file of your app package and\nimport ``django.conf.settings`` in it, too:\n\n.. code-block:: python\n\n from django.conf import settings\n from appconf import AppConf\n\n class MyAppConf(AppConf):\n SETTING_1 = \"one\"\n SETTING_2 = (\n \"two\",\n )\n\nIn the other files of your app you can easily make sure the settings\nare correctly loaded if you import Django's settings object from that\nmodule, e.g. in your app's ``views.py``:\n\n.. code-block:: python\n\n from django.http import HttpResponse\n from myapp.conf import settings\n\n def index(request):\n text = 'Setting 1 is: %s' % settings.MYAPP_SETTING_1\n return HttpResponse(text)\n\n",
"bugtrack_url": null,
"license": "BSD",
"summary": "A helper class for handling configuration defaults of packaged apps gracefully.",
"version": "1.0.6",
"project_urls": {
"Homepage": "https://django-appconf.readthedocs.io/",
"Source": "https://github.com/django-compressor/django-appconf"
},
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "c0981cb3d9e8b1c6d0a74539b998474796fc5c0c0888b6201e5c95ba2f7a0677",
"md5": "04d640318dd06d64afde85fae6d09531",
"sha256": "c3ae442fba1ff7ec830412c5184b17169a7a1e71cf0864a4c3f93cf4c98a1993"
},
"downloads": -1,
"filename": "django_appconf-1.0.6-py3-none-any.whl",
"has_sig": false,
"md5_digest": "04d640318dd06d64afde85fae6d09531",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.7",
"size": 6424,
"upload_time": "2023-11-20T19:24:59",
"upload_time_iso_8601": "2023-11-20T19:24:59.746735Z",
"url": "https://files.pythonhosted.org/packages/c0/98/1cb3d9e8b1c6d0a74539b998474796fc5c0c0888b6201e5c95ba2f7a0677/django_appconf-1.0.6-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "65e0704b6453f21fac22f0ab128150e9782b7d38bc1ed09710ac2197ddc1751f",
"md5": "09e9da7bb4ff3d50db288faaa127f933",
"sha256": "cfe87ea827c4ee04b9a70fab90b86d704cb02f2981f89da8423cb0fabf88efbf"
},
"downloads": -1,
"filename": "django-appconf-1.0.6.tar.gz",
"has_sig": false,
"md5_digest": "09e9da7bb4ff3d50db288faaa127f933",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.7",
"size": 15895,
"upload_time": "2023-11-20T19:25:01",
"upload_time_iso_8601": "2023-11-20T19:25:01.840479Z",
"url": "https://files.pythonhosted.org/packages/65/e0/704b6453f21fac22f0ab128150e9782b7d38bc1ed09710ac2197ddc1751f/django-appconf-1.0.6.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-11-20 19:25:01",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "django-compressor",
"github_project": "django-appconf",
"travis_ci": false,
"coveralls": true,
"github_actions": true,
"tox": true,
"lcname": "django-appconf"
}
JSON
