METADATA 4.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136
  1. Metadata-Version: 2.0
  2. Name: django-appconf
  3. Version: 1.0.1
  4. Summary: A helper class for handling configuration defaults of packaged apps gracefully.
  5. Home-page: http://django-appconf.readthedocs.org/
  6. Author: Jannis Leidel
  7. Author-email: jannis@leidel.info
  8. License: BSD
  9. Platform: UNKNOWN
  10. Classifier: Development Status :: 5 - Production/Stable
  11. Classifier: Environment :: Web Environment
  12. Classifier: Framework :: Django
  13. Classifier: Intended Audience :: Developers
  14. Classifier: License :: OSI Approved :: BSD License
  15. Classifier: Operating System :: OS Independent
  16. Classifier: Programming Language :: Python
  17. Classifier: Programming Language :: Python :: 2
  18. Classifier: Programming Language :: Python :: 2.6
  19. Classifier: Programming Language :: Python :: 2.7
  20. Classifier: Programming Language :: Python :: 3
  21. Classifier: Programming Language :: Python :: 3.2
  22. Classifier: Programming Language :: Python :: 3.3
  23. Classifier: Programming Language :: Python :: 3.4
  24. Classifier: Topic :: Utilities
  25. Requires-Dist: six
  26. django-appconf
  27. ==============
  28. .. image:: https://secure.travis-ci.org/jezdez/django-appconf.png?branch=develop
  29. :alt: Build Status
  30. :target: http://travis-ci.org/jezdez/django-appconf
  31. A helper class for handling configuration defaults of packaged Django
  32. apps gracefully.
  33. .. note::
  34. This app precedes Django's own AppConfig_ classes that act as
  35. "objects [to] store metadata for an application" inside Django's
  36. app loading mechanism. In other words, they solve a related but
  37. different use case than django-appconf and can't easily be used
  38. as a replacement. The similarity in name is purely coincidental.
  39. .. _AppConfig: https://docs.djangoproject.com/en/stable/ref/applications/#django.apps.AppConfig
  40. Overview
  41. --------
  42. Say you have an app called ``myapp`` with a few defaults, which you want
  43. to refer to in the app's code without repeating yourself all the time.
  44. ``appconf`` provides a simple class to implement those defaults. Simply add
  45. something like the following code somewhere in your app files::
  46. from appconf import AppConf
  47. class MyAppConf(AppConf):
  48. SETTING_1 = "one"
  49. SETTING_2 = (
  50. "two",
  51. )
  52. .. note::
  53. ``AppConf`` classes depend on being imported during startup of the Django
  54. process. Even though there are multiple modules loaded automatically,
  55. only the ``models`` modules (usually the ``models.py`` file of your
  56. app) are guaranteed to be loaded at startup. Therefore it's recommended
  57. to put your ``AppConf`` subclass(es) there, too.
  58. The settings are initialized with the capitalized app label of where the
  59. setting is located at. E.g. if your ``models.py`` with the ``AppConf`` class
  60. is in the ``myapp`` package, the prefix of the settings will be ``MYAPP``.
  61. You can override the default prefix by specifying a ``prefix`` attribute of
  62. an inner ``Meta`` class::
  63. from appconf import AppConf
  64. class AcmeAppConf(AppConf):
  65. SETTING_1 = "one"
  66. SETTING_2 = (
  67. "two",
  68. )
  69. class Meta:
  70. prefix = 'acme'
  71. The ``MyAppConf`` class will automatically look at Django's global settings
  72. to determine if you've overridden it. For example, adding this to your site's
  73. ``settings.py`` would override ``SETTING_1`` of the above ``MyAppConf``::
  74. ACME_SETTING_1 = "uno"
  75. In case you want to use a different settings object instead of the default
  76. ``'django.conf.settings'``, set the ``holder`` attribute of the inner
  77. ``Meta`` class to a dotted import path::
  78. from appconf import AppConf
  79. class MyAppConf(AppConf):
  80. SETTING_1 = "one"
  81. SETTING_2 = (
  82. "two",
  83. )
  84. class Meta:
  85. prefix = 'acme'
  86. holder = 'acme.conf.settings'
  87. If you ship an ``AppConf`` class with your reusable Django app, it's
  88. recommended to put it in a ``conf.py`` file of your app package and
  89. import ``django.conf.settings`` in it, too::
  90. from django.conf import settings
  91. from appconf import AppConf
  92. class MyAppConf(AppConf):
  93. SETTING_1 = "one"
  94. SETTING_2 = (
  95. "two",
  96. )
  97. In the other files of your app you can easily make sure the settings
  98. are correctly loaded if you import Django's settings object from that
  99. module, e.g. in your app's ``views.py``::
  100. from django.http import HttpResponse
  101. from myapp.conf import settings
  102. def index(request):
  103. text = 'Setting 1 is: %s' % settings.MYAPP_SETTING_1
  104. return HttpResponse(text)