django-appconf
==============
.. image:: https://github.com/django-compressor/django-appconf/actions/workflows/tests.yml/badge.svg
:alt: Build Status
:target: https://github.com/django-compressor/django-appconf/actions/workflows/tests.yml
.. image:: https://badge.fury.io/py/django-appconf.svg
:alt: PyPI version
:target: https://pypi.org/project/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": null,
"docs_url": null,
"requires_python": ">=3.9",
"maintainer_email": null,
"keywords": null,
"author": "Jannis Leidel",
"author_email": "jannis@leidel.info",
"download_url": "https://files.pythonhosted.org/packages/61/a9/dcf95ff3fa0620b6818fc02276fbbb8926e7f286039b6d015e56e8b7af39/django-appconf-1.1.0.tar.gz",
"platform": null,
"description": "django-appconf\n==============\n\n.. image:: https://github.com/django-compressor/django-appconf/actions/workflows/tests.yml/badge.svg\n :alt: Build Status\n :target: https://github.com/django-compressor/django-appconf/actions/workflows/tests.yml\n\n.. image:: https://badge.fury.io/py/django-appconf.svg\n :alt: PyPI version\n :target: https://pypi.org/project/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.1.0",
"project_urls": {
"Homepage": "https://django-appconf.readthedocs.io/",
"Source": "https://github.com/django-compressor/django-appconf"
},
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "629ef3a899991e4aaae4b69c1aa187ba4a32e34742475c91eb13010ee7fbe9db",
"md5": "e47a5eafb8fc17609c7bff5701176421",
"sha256": "7abd5a163ff57557f216e84d3ce9dac36c37ffce1ab9a044d3d53b7c943dd10f"
},
"downloads": -1,
"filename": "django_appconf-1.1.0-py3-none-any.whl",
"has_sig": false,
"md5_digest": "e47a5eafb8fc17609c7bff5701176421",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.9",
"size": 6389,
"upload_time": "2025-02-13T16:09:39",
"upload_time_iso_8601": "2025-02-13T16:09:39.133173Z",
"url": "https://files.pythonhosted.org/packages/62/9e/f3a899991e4aaae4b69c1aa187ba4a32e34742475c91eb13010ee7fbe9db/django_appconf-1.1.0-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "61a9dcf95ff3fa0620b6818fc02276fbbb8926e7f286039b6d015e56e8b7af39",
"md5": "b2a0c2a1cb19bf93144904792e3a3a2b",
"sha256": "9fcead372f82a0f21ee189434e7ae9c007cbb29af1118c18251720f3d06243e4"
},
"downloads": -1,
"filename": "django-appconf-1.1.0.tar.gz",
"has_sig": false,
"md5_digest": "b2a0c2a1cb19bf93144904792e3a3a2b",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.9",
"size": 15986,
"upload_time": "2025-02-13T16:09:40",
"upload_time_iso_8601": "2025-02-13T16:09:40.258186Z",
"url": "https://files.pythonhosted.org/packages/61/a9/dcf95ff3fa0620b6818fc02276fbbb8926e7f286039b6d015e56e8b7af39/django-appconf-1.1.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2025-02-13 16:09:40",
"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
