Coder Social home page Coder Social logo

django-compressor / django-appconf Goto Github PK

View Code? Open in Web Editor NEW
349.0 16.0 47.0 114 KB

An app to handle configuration defaults of packaged Django apps gracefully

Home Page: https://django-appconf.readthedocs.io

License: BSD 3-Clause "New" or "Revised" License

Python 100.00%

django-appconf's Introduction

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"

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:

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)

django-appconf's People

Contributors

aleksihakli avatar amizya avatar carltongibson avatar chambersh1129 avatar diox avatar dvzrv avatar entequak avatar giff-h avatar gotgenes avatar hsmett avatar jezdez avatar joehybird avatar lcd1232 avatar matthewwithanm avatar morganead avatar nikolas avatar paduszyk avatar pakal avatar paltman avatar philippbosch avatar rafales avatar scop avatar sobolevn avatar streeter avatar treyhunner avatar twz915 avatar wtayyeb avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

django-appconf's Issues

Missing settings in test classmethod setUpTestData()

Python 2.7

Django==1.8.18
django-appconf==1.0.2
pytest==3.4.1
pytest-cov==2.5.1
pytest-django==3.1.2

AppConf settings will be not available in test classmethod setUpTestData() or setUpClass()
Maybe it depend on django-pytest and his test runner ?!?

I tried to add a apps.py similar to: https://github.com/julen/django-statici18n/commit/7638920e7be8247857fad36b422d977bcac3cf60
But this doesn't help.

I tried to import the app config class in setUpTestData() or setUpClass() but this doesn't the settings, too.

The only work-a-round for me was to add the settings manually in settings.py :(

Do you need a new maintainer?

Hello.

I use Django Compressor so rely on AppConf.

Do you need a maintainer here? (Currently doing DRF, Django Filter and Crispy Forms — I'm happy to take this on — since I've a vested interest.)

AppConf subclass settings disappear in second and subsequent uses of override_settings

(This might be related to #29 but since the symptoms are different I'm creating a new issue.)

If you've added settings using a subclass of AppConf from a Django application, it seems that those settings are available in the first override_settings-wrapped method, but not in subsequent ones.

I created a minimal django project to demonstrate this, which you can clone from here: https://github.com/mhl/django-appconf-test

The AppConf subclass, which is used in the only view, is:

class ExampleExtraConf(AppConf):
    MY_EXTRA_SETTING = 'foo'

... and the two (identical) tests are:

from django.test import TestCase
from django.test.utils import override_settings


class ExampleTests(TestCase):

    @override_settings(MEDIA_ROOT='/var/tmp/')
    def test_once(self):
        response = self.client.get('/')
        self.assertContains(response, 'foo')

    @override_settings(MEDIA_ROOT='/var/tmp/')
    def test_twice(self):
        response = self.client.get('/')
        self.assertContains(response, 'foo')

You'll find that test_once passes, but test_twice fails:

 ./manage.py test
Creating test database for alias 'default'...
.E
======================================================================
ERROR: test_twice (myproject.tests.ExampleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mark/.virtualenvs/minimal-django-test-project/local/lib/python2.7/site-packages/django/test/utils.py", line 196, in inner
    return test_func(*args, **kwargs)
  File "/home/mark/minimal-django-test-project/myproject/tests.py", line 14, in test_twice
    response = self.client.get('/')
  File "/home/mark/.virtualenvs/minimal-django-test-project/local/lib/python2.7/site-packages/django/test/client.py", line 500, in get
    **extra)
  File "/home/mark/.virtualenvs/minimal-django-test-project/local/lib/python2.7/site-packages/django/test/client.py", line 303, in get
    return self.generic('GET', path, secure=secure, **r)
  File "/home/mark/.virtualenvs/minimal-django-test-project/local/lib/python2.7/site-packages/django/test/client.py", line 379, in generic
    return self.request(**r)
  File "/home/mark/.virtualenvs/minimal-django-test-project/local/lib/python2.7/site-packages/django/test/client.py", line 466, in request
    six.reraise(*exc_info)
  File "/home/mark/.virtualenvs/minimal-django-test-project/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 132, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/mark/minimal-django-test-project/example/views.py", line 7, in homepage
    settings.EXAMPLE_MY_EXTRA_SETTING
  File "/home/mark/.virtualenvs/minimal-django-test-project/local/lib/python2.7/site-packages/django/conf/__init__.py", line 49, in __getattr__
    return getattr(self._wrapped, name)
  File "/home/mark/.virtualenvs/minimal-django-test-project/local/lib/python2.7/site-packages/django/conf/__init__.py", line 160, in __getattr__
    return getattr(self.default_settings, name)
AttributeError: 'Settings' object has no attribute 'EXAMPLE_MY_EXTRA_SETTING'

----------------------------------------------------------------------
Ran 2 tests in 0.045s

FAILED (errors=1)
Destroying test database for alias 'default'...

To help people who find this via Google, we came across this when finding that the django-statici18n statici18n template tag was failing in some tests where override_settings was used, producing a traceback like:

  File "/home/mark/.virtualenvs/ynr-popolo-upstream/local/lib/python2.7/site-packages/django/template/base.py", line 1197, in render
    return func(*resolved_args, **resolved_kwargs)
  File "/home/mark/.virtualenvs/ynr-popolo-upstream/local/lib/python2.7/site-packages/statici18n/templatetags/statici18n.py", line 34, in statici18n
    return static(get_path(locale))
  File "/home/mark/.virtualenvs/ynr-popolo-upstream/local/lib/python2.7/site-packages/statici18n/templatetags/statici18n.py", line 21, in get_path
    return os.path.join(settings.STATICI18N_OUTPUT_DIR,
  File "/home/mark/.virtualenvs/ynr-popolo-upstream/local/lib/python2.7/site-packages/django/conf/__init__.py", line 49, in __getattr__
    return getattr(self._wrapped, name)
  File "/home/mark/.virtualenvs/ynr-popolo-upstream/local/lib/python2.7/site-packages/django/conf/__init__.py", line 160, in __getattr__
    return getattr(self.default_settings, name)
AttributeError: 'Settings' object has no attribute 'STATICI18N_OUTPUT_DIR'

pypi sdist doesn't contain tests

When packaging 1.0.3 for Arch Linux I tried to run the tests, but they're not included in the pypi sdist.

Tests are important, especially on a distribution packaging level, as that way one can ensure, that the components integrate with the system.

Warning Django 1.9

Please, update your app, now we have this warning:

/home/tulipan/Proyectos/TiempoTurco/lib/python3.4/importlib/_bootstrap.py:321: RemovedInDjango19Warning: django.utils.importlib will be removed in Django 1.9.
  return f(*args, **kwds)

Error when using django-related imports in settings.py

Hi, thanks for a great app
I get the problem mentioned here:
django-compressor/django-compressor#333
and here:
django-compressor/django-compressor#273

I traced it to the appconf application, AppConfOptions, line:
self.holder_path = getattr(meta, 'holder', 'django.conf.settings')

The problem is that in my project I set DJANGO_SETTINGS_MODULE to a local settings file
(I use different settings in local and production)
the problem disappears when I change 'django.conf.settings' to my local settings file. Should the app check the DJANGO_SETTINGS_MODULE var, instead of assuming it's 'django.conf.settings'?

Do there any blockers to bump new release?

We are looking forward to using django-appconf with Django 3.2 on edX.

Develop branch is already tested against Django 3.2.
Do there any chance a new version will be bumped soon?

If any blockers with the release I would be happy to help.

Thank you in advance.

tests __pycache__ data in pypi sdist tarball makes packaging unreproducible

Hi! When rebuilding the package for 1.0.4 on Arch Linux I ran our reproducible builds tooling against the package.
Unfortunately the __pacache__ data found in the tarball makes the package unreproducible.

The diffoscope output:

--- python-django-appconf-1.0.4-2-any.pkg.tar.zst
+++ build/python-django-appconf-1.0.4-2-any.pkg.tar.zst
├── python-django-appconf-1.0.4-2-any.pkg.tar
│ ├── file list
│ │ @@ -1,9 +1,9 @@
│ │  -rw-r--r--   0 root         (0) root         (0)     5267 2020-07-15 20:27:00.000000 .BUILDINFO
│ │ --rw-r--r--   0 root         (0) root         (0)     1638 2020-07-15 20:27:00.000000 .MTREE
│ │ +-rw-r--r--   0 root         (0) root         (0)     1637 2020-07-15 20:27:00.000000 .MTREE
│ │  -rw-r--r--   0 root         (0) root         (0)      521 2020-07-15 20:27:00.000000 .PKGINFO
│ │  drwxr-xr-x   0 root         (0) root         (0)        0 2020-07-15 20:27:00.000000 usr/
│ │  drwxr-xr-x   0 root         (0) root         (0)        0 2020-07-15 20:27:00.000000 usr/lib/
│ │  drwxr-xr-x   0 root         (0) root         (0)        0 2020-07-15 20:27:00.000000 usr/lib/python3.8/
│ │  drwxr-xr-x   0 root         (0) root         (0)        0 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/
│ │  drwxr-xr-x   0 root         (0) root         (0)        0 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/appconf/
│ │  -rw-r--r--   0 root         (0) root         (0)       57 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/appconf/__init__.py
│ │ @@ -14,15 +14,15 @@
│ │  -rw-r--r--   0 root         (0) root         (0)     4714 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/appconf/__pycache__/base.cpython-38.pyc
│ │  -rw-r--r--   0 root         (0) root         (0)      722 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/appconf/__pycache__/utils.cpython-38.opt-1.pyc
│ │  -rw-r--r--   0 root         (0) root         (0)      722 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/appconf/__pycache__/utils.cpython-38.pyc
│ │  -rw-r--r--   0 root         (0) root         (0)     5181 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/appconf/base.py
│ │  -rw-r--r--   0 root         (0) root         (0)      861 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/appconf/utils.py
│ │  drwxr-xr-x   0 root         (0) root         (0)        0 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/
│ │  -rw-r--r--   0 root         (0) root         (0)     5998 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/PKG-INFO
│ │ --rw-r--r--   0 root         (0) root         (0)      834 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/SOURCES.txt
│ │ +-rw-r--r--   0 root         (0) root         (0)      666 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/SOURCES.txt
│ │  -rw-r--r--   0 root         (0) root         (0)        1 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/dependency_links.txt
│ │  -rw-r--r--   0 root         (0) root         (0)        7 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/requires.txt
│ │  -rw-r--r--   0 root         (0) root         (0)        8 2020-07-15 20:27:00.000000 usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/top_level.txt
│ │  drwxr-xr-x   0 root         (0) root         (0)        0 2020-07-15 20:27:00.000000 usr/share/
│ │  drwxr-xr-x   0 root         (0) root         (0)        0 2020-07-15 20:27:00.000000 usr/share/doc/
│ │  drwxr-xr-x   0 root         (0) root         (0)        0 2020-07-15 20:27:00.000000 usr/share/doc/python-django-appconf/
│ │  -rw-r--r--   0 root         (0) root         (0)       91 2020-07-15 20:27:00.000000 usr/share/doc/python-django-appconf/AUTHORS
│ ├── .MTREE
│ │ ├── .MTREE-content
│ │ │ @@ -1,11 +1,11 @@
│ │ │  #mtree
│ │ │  /set type=file uid=0 gid=0 mode=644
│ │ │  ./.BUILDINFO time=1594844820.0 size=5267 md5digest=6299c5cad295b5a554fc329a23172992 sha256digest=3fb781c7b5f62a369060c7b8b0b65d5518fa5fbd8ef1bac999fbd6ae765de614
│ │ │ -./.PKGINFO time=1594844820.0 size=521 md5digest=4437e18c8a24b63e722e0f1884e05579 sha256digest=e3a3a3f5dca8a5c8a757bdbb2105673605265b1f572abcb03c2fb0cf5cab3aff
│ │ │ +./.PKGINFO time=1594844820.0 size=521 md5digest=15f505c0ba63e11cd28db270c77ebf82 sha256digest=cbf99e1cfeb6bf2fb50d5312754bc3a9e1948408d543da580ca51162268b36f5
│ │ │  /set mode=755
│ │ │  ./usr time=1594844820.0 type=dir
│ │ │  ./usr/lib time=1594844820.0 type=dir
│ │ │  ./usr/lib/python3.8 time=1594844820.0 type=dir
│ │ │  ./usr/lib/python3.8/site-packages time=1594844820.0 type=dir
│ │ │  /set mode=644
│ │ │  ./usr/lib/python3.8/site-packages/appconf time=1594844820.0 mode=755 type=dir
│ │ │ @@ -17,15 +17,15 @@
│ │ │  ./usr/lib/python3.8/site-packages/appconf/__pycache__/__init__.cpython-38.pyc time=1594844820.0 size=205 md5digest=f5bcab9e6c3236cfaee0627ba7c3e9a4 sha256digest=9c9ec95e9c9c92fc32314a42a1f9d58dd95dc6a29e8861282a329bd9fd87f9b6
│ │ │  ./usr/lib/python3.8/site-packages/appconf/__pycache__/base.cpython-38.opt-1.pyc time=1594844820.0 size=4714 md5digest=bf47d7a975cfbaa8d687538ff1f22d9c sha256digest=31d4eb93a4c59c9bd79cd051b5d35c8a5c54bf5d08c00e7f4f96f4e537f55bc3
│ │ │  ./usr/lib/python3.8/site-packages/appconf/__pycache__/base.cpython-38.pyc time=1594844820.0 size=4714 md5digest=ffd61114730ce4ef49c2cdccbb19f49a sha256digest=69e495b19ac4513333c3b6f5441802a16c0301133f169780d9832f362f655b3c
│ │ │  ./usr/lib/python3.8/site-packages/appconf/__pycache__/utils.cpython-38.opt-1.pyc time=1594844820.0 size=722 md5digest=59a810d0963b9e62af32fe6c218f810a sha256digest=643c5b82200caf79278a8fcb4cbb8c19188e09f7942879be5335054efc2242e1
│ │ │  ./usr/lib/python3.8/site-packages/appconf/__pycache__/utils.cpython-38.pyc time=1594844820.0 size=722 md5digest=7a6a2652ce03e713e55236aa75cf3c9e sha256digest=6cf0c7929555b5746410e73c3999ea357fdd7652a820e43ecf1508e43d41b1b3
│ │ │  ./usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info time=1594844820.0 mode=755 type=dir
│ │ │  ./usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/PKG-INFO time=1594844820.0 size=5998 md5digest=abc213792ad4b89405c5035cc3f5ab94 sha256digest=51fdc7a8bcca9dedf67bd4f0e3a6e6781e648256ab734a0994df353e66d66c3f
│ │ │ -./usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/SOURCES.txt time=1594844820.0 size=834 md5digest=caa3c4e2faa327037e47c15f51b151fd sha256digest=0c288ae70d348cec450bb5a160a96a0d5deb441b2f473d3f4b56bc166ad61677
│ │ │ +./usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/SOURCES.txt time=1594844820.0 size=666 md5digest=50179acd1ea1c44f1168b73acebcfd6c sha256digest=cdfbed1aec98df9f190aea521c4cf4332d87b39c30da3a881556810b497f5a1c
│ │ │  ./usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/dependency_links.txt time=1594844820.0 size=1 md5digest=68b329da9893e34099c7d8ad5cb9c940 sha256digest=01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b
│ │ │  ./usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/requires.txt time=1594844820.0 size=7 md5digest=bea59528d92a016338600bf69118c5ab sha256digest=57f8288a383db5f3b6d28c7fee8b3a09c9cfbe605abdbc6ee3a2e926234bc230
│ │ │  ./usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/top_level.txt time=1594844820.0 size=8 md5digest=c3aa368fedd37101d3d4a373e0d97c05 sha256digest=6cbc70de4b67de3eba0de6c567b866ac511c519489cc7cff72784bd7a5a737b9
│ │ │  /set mode=755
│ │ │  ./usr/share time=1594844820.0 type=dir
│ │ │  ./usr/share/doc time=1594844820.0 type=dir
│ │ │  /set mode=644
│ ├── .PKGINFO
│ │ @@ -3,15 +3,15 @@
│ │  pkgname = python-django-appconf
│ │  pkgbase = python-django-appconf
│ │  pkgver = 1.0.4-2
│ │  pkgdesc = An app to handle configuration defaults of packaged Django apps gracefully
│ │  url = https://github.com/django-compressor/django-appconf
│ │  builddate = 1594844820
│ │  packager = David Runge <[email protected]>
│ │ -size = 29714
│ │ +size = 29546
│ │  arch = any
│ │  license = BSD
│ │  depend = python-django
│ │  depend = python-six
│ │  makedepend = python-setuptools
│ │  checkdepend = python-coverage
│ │  checkdepend = python-pytest
│ ├── usr/lib/python3.8/site-packages/django_appconf-1.0.4-py3.8.egg-info/SOURCES.txt
│ │ @@ -21,14 +21,10 @@
│ │  docs/usage.rst
│ │  tests/__init__.py
│ │  tests/models.py
│ │  tests/settings.py
│ │  tests/test_settings.py
│ │  tests/tests.py
│ │  tests/__pycache__/__init__.cpython-37.pyc
│ │ -tests/__pycache__/__init__.cpython-38.pyc
│ │  tests/__pycache__/models.cpython-37.pyc
│ │ -tests/__pycache__/models.cpython-38.pyc
│ │  tests/__pycache__/test_settings.cpython-37.pyc
│ │ -tests/__pycache__/test_settings.cpython-38.pyc
│ │ -tests/__pycache__/tests.cpython-37.pyc
│ │ -tests/__pycache__/tests.cpython-38.pyc
│ │ +tests/__pycache__/tests.cpython-37.pyc

The package only becomes reproducible if I remove the tests/__pycache__ directory before build and after testing.

Version 1.0.4 is broken for Python 2

I see version 1.0.4 just removed and broke compatibility with Python 2, this is a bit frustrating as minor and patch versions should never break compatibility.

Please consider releasing 1.0.4 as a major version instead according to the https://semver.org/ guidelines.

django3 support

this library does not support django3 currently

  File "/Users/myuser/.virtualenvs/myenv/lib/python3.6/site-packages/appconf/__init__.py", line 2, in <module>
    from .base import AppConf  # noqa
  File "/Users/myuser/.virtualenvs/myenv/lib/python3.6/site-packages/appconf/base.py", line 4, in <module>
    from django.utils import six
ImportError: cannot import name 'six'

Update Tox and Travis configs.

There's a few errors running tox on a clean checkout (summary below).

I'm not quite sure what's wrong with py27-dj18 and py27-dj19 at this moment (will investigate) but py32-dj19 and py33-dj19 are no longer supported combinations.

I will update the test matrix for both Tox and Travis to the supported Django/Python combinations.

___________________________ summary _________________________________
  flake8-py27: commands succeeded
  flake8-py33: commands succeeded
  py26-dj14: commands succeeded
  py27-dj14: commands succeeded
  py26-dj15: commands succeeded
  py26-dj16: commands succeeded
  py27-dj15: commands succeeded
  py27-dj16: commands succeeded
  py32-dj15: commands succeeded
  py32-dj16: commands succeeded
  py33-dj15: commands succeeded
  py33-dj16: commands succeeded
  py27-dj17: commands succeeded
ERROR:   py27-dj18: could not install deps [flake8, coverage, django-discover-runner, https://github.com/django/django/archive/stable/1.8.x.zip#egg=django]; v = InvocationError('.../django-appconf/.tox/py27-dj18/bin/pip install flake8 coverage django-discover-runner https://github.com/django/django/archive/stable/1.8.x.zip#egg=django (see .../django-appconf/.tox/py27-dj18/log/py27-dj18-1.log)', 2)
ERROR:   py27-dj19: could not install deps [flake8, coverage, django-discover-runner, https://github.com/django/django/archive/master.zip#egg=django]; v = InvocationError('.../django-appconf/.tox/py27-dj19/bin/pip install flake8 coverage django-discover-runner https://github.com/django/django/archive/master.zip#egg=django (see .../django-appconf/.tox/py27-dj19/log/py27-dj19-1.log)', 2)
  py32-dj17: commands succeeded
  py32-dj18: commands succeeded
ERROR:   py32-dj19: commands failed
  py33-dj17: commands succeeded
  py33-dj18: commands succeeded
ERROR:   py33-dj19: commands failed
  py34-dj17: commands succeeded
  py34-dj18: commands succeeded
  py34-dj19: commands succeeded

Missing tags

Hi! 👋

I package this project for Arch Linux. We rely on upstream source tarballs (https://rfc.archlinux.page/0020-sources-for-python-packaging/), as pypi sdist tarballs are not well-defined and often unfortunately insufficient or broken.

This project unfortunately misses the tags for the last two releases 1.0.5 and 1.0.6 and therefore downstreams can not make use of auto-generated source tarballs here on github.

Could you please add the relevant tags? Thanks! :)

How does `django-appconf` interact with "Automatic `AppConfig` discovery" in Django 3.2?

The Django 3.2 release notes describe the following new feature:

Automatic AppConfig discovery

Most pluggable applications define an AppConfig subclass in an apps.py submodule. Many define a default_app_config variable pointing to this class in their __init__.py.

When the apps.py submodule exists and defines a single AppConfig subclass, Django now uses that configuration automatically, so you can remove default_app_config.

Does this make django-appconf redundant for Django 3.2+?

1.0.3 not present in github

This means there doesn't appear to be any source available for 1.0.3 that includes the tests, important for people who need to assert that they've built their packages correctly.

Question about usage with Celery

I am trying to use django-appconf to carry some celery settings into the host project (ie CELERY_RESULT_BACKEND). Broadly speaking, is this a valid use case for django-appconf? I am concerned that Django will try to initialize the Celery app object before django-appconf modifies the host project settings.

No python module

AppConf breaks Django model loading. I use an app that uses Django's get_model function to load a model. The problem is that AppConf is no real python module (with __init__ and an own directory and stuff). So get_model breaks with

self.load_app(app_name, True)
  File "/usr/local/Cellar/python/2.7.1/lib/python2.7/site-packages/django/db/models/loading.py", line 83, in load_app
    if not module_has_submodule(app_module, 'models'):
  File "/usr/local/Cellar/python/2.7.1/lib/python2.7/site-packages/django/utils/module_loading.py", line 18, in module_has_submodule
    for entry in package.__path__:  # No __path__, then not a package.
AttributeError: 'module' object has no attribute '__path__'

update to 1.0.4 failed project

Hi, after your update from 1.0.3 to 1.0.4, my pipeline in project are failing.

  File "/home/user/projects/project/venv/local/lib/python2.7/site-packages/appconf/base.py", line 107
    class AppConf(metaclass=AppConfMetaClass):
                           ^
SyntaxError: invalid syntax

I had resolve my problem with downgrade version of package, but i think you need to fix it.

Python 2.7
Django 1.11

maintainance

hi there
I like the concept of this small helper - is it maintained somewhere else?

thx!

Question: Is it possible to override settings from django?

In my app I'm trying to override a setting that has a default in django (LOGIN_URL) based on a special setting in my app.

I tried setting LOGIN_URL on an AppConf with Meta.prefix = '', but that obviously just picks up the default setting from django (LOGIN_URL='/accounts/login') instead of using the default value specified on my configuration.

RuntimeError: super(): empty __class__ cell

First off, thx for the cool package:

I'm mostly noting this here in case others encounter the same issue.

Calling super configure fails in AppConf subclasses:

How to reproduce:

mktmpenv # assuming virtualenvwrapper is installed
python --version
# Python 3.10.13
pip install django==4.2.7 django-appconf==1.0.5 # these are the current versions at time of writing
mkdir test
cd test
django-admin startproject demo
cd demo
./manage.py startapp app
  • add app to INSTALLED_APPS in demo/settings.py
  • add this at the end of app/apps.py
from appconf import AppConf

class MyAppConf(AppConf):
    SETTING_1 = "one"
    SETTING_2 = "two"
    
    def configure(self):
        print("before fail")
        return super().configure()
  • now run the server with ./manage.py runserver
  • it fails with:
mskoenz:demo$ ./manage.py runserver
before fail
before fail
Watching for file changes with StatReloader
Exception in thread django-main-thread:
Traceback (most recent call last):
  File "/opt/homebrew/Cellar/[email protected]/3.10.13/Frameworks/Python.framework/Versions/3.10/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/opt/homebrew/Cellar/[email protected]/3.10.13/Frameworks/Python.framework/Versions/3.10/lib/python3.10/threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "/Users/mskoenz/.virtualenvs/tmp-7c6bbf99066cd53/lib/python3.10/site-packages/django/utils/autoreload.py", line 64, in wrapper
    fn(*args, **kwargs)
  File "/Users/mskoenz/.virtualenvs/tmp-7c6bbf99066cd53/lib/python3.10/site-packages/django/core/management/commands/runserver.py", line 125, in inner_run
    autoreload.raise_last_exception()
  File "/Users/mskoenz/.virtualenvs/tmp-7c6bbf99066cd53/lib/python3.10/site-packages/django/utils/autoreload.py", line 87, in raise_last_exception
    raise _exception[1]
  File "/Users/mskoenz/.virtualenvs/tmp-7c6bbf99066cd53/lib/python3.10/site-packages/django/core/management/__init__.py", line 394, in execute
    autoreload.check_errors(django.setup)()
  File "/Users/mskoenz/.virtualenvs/tmp-7c6bbf99066cd53/lib/python3.10/site-packages/django/utils/autoreload.py", line 64, in wrapper
    fn(*args, **kwargs)
  File "/Users/mskoenz/.virtualenvs/tmp-7c6bbf99066cd53/lib/python3.10/site-packages/django/__init__.py", line 24, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/Users/mskoenz/.virtualenvs/tmp-7c6bbf99066cd53/lib/python3.10/site-packages/django/apps/registry.py", line 91, in populate
    app_config = AppConfig.create(entry)
  File "/Users/mskoenz/.virtualenvs/tmp-7c6bbf99066cd53/lib/python3.10/site-packages/django/apps/config.py", line 123, in create
    mod = import_module(mod_path)
  File "/opt/homebrew/Cellar/[email protected]/3.10.13/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/Users/mskoenz/programming/demo/app/apps.py", line 10, in <module>
    class MyAppConf(AppConf):
  File "/Users/mskoenz/.virtualenvs/tmp-7c6bbf99066cd53/lib/python3.10/site-packages/appconf/base.py", line 73, in __new__
    new_class._configure()
  File "/Users/mskoenz/.virtualenvs/tmp-7c6bbf99066cd53/lib/python3.10/site-packages/appconf/base.py", line 104, in _configure
    cls._meta.configured_data = obj.configure()
  File "/Users/mskoenz/programming/demo/app/apps.py", line 16, in configure
    return super().configure()
RuntimeError: super(): empty __class__ cell
  • if you comment the def configure(self): function and run ./manage.py runserver, it works (for me):
mskoenz:demo$ ./manage.py runserver
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).

You have 18 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
November 14, 2023 - 06:23:11
Django version 4.2.7, using settings 'demo.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

1.0.3: Failing tests

When packaging 1.0.3 for Arch Linux I ran the test suite as such:

export PYTHONPATH="${PWD}:build:${PYTHONPATH}"
DJANGO_SETTINGS_MODULE=tests.test_settings coverage run /usr/bin/django-admin.py test -v2 tests

which leads to five failing tests.
I'm probably missing something here. Any hints would be very much appreciated!

Creating test database for alias 'default' ('file:memorydb_default?mode=memory&cache=shared')...
Destroying test database for alias 'default' ('file:memorydb_default?mode=memory&cache=shared')...
SystemCheckError: System check identified some issues:

ERRORS:
?: (admin.E403) A 'django.template.backends.django.DjangoTemplates' instance must be configured in TEMPLATES in order to use the admin application.
?: (admin.E406) 'django.contrib.messages' must be in INSTALLED_APPS in order to use the admin application.
?: (admin.E408) 'django.contrib.auth.middleware.AuthenticationMiddleware' must be in MIDDLEWARE in order to use the admin application.
?: (admin.E409) 'django.contrib.messages.middleware.MessageMiddleware' must be in MIDDLEWARE in order to use the admin application.
?: (admin.E410) 'django.contrib.sessions.middleware.SessionMiddleware' must be in MIDDLEWARE in order to use the admin application.

System check identified 5 issues (0 silenced).
Operations to perform:
  Synchronize unmigrated apps: tests
  Apply all migrations: admin, auth, contenttypes, sites
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying sites.0001_initial... OK
  Applying sites.0002_alter_domain_unique... OK

Error after upgrading from 1.0.3 to 1.0.4

Unhandled exception in thread started by <function wrapper at 0x7efff16956e0>
Traceback (most recent call last):
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/django/utils/autoreload.py", line 228, in wrapper
    fn(*args, **kwargs)
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/django/core/management/commands/runserver.py", line 116, in inner_run
    autoreload.raise_last_exception()
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/django/utils/autoreload.py", line 251, in raise_last_exception
    six.reraise(*_exception)
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/django/utils/autoreload.py", line 228, in wrapper
    fn(*args, **kwargs)
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/django/__init__.py", line 27, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/django/apps/registry.py", line 85, in populate
    app_config = AppConfig.create(entry)
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/django/apps/config.py", line 94, in create
    module = import_module(entry)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/imagekit/__init__.py", line 2, in <module>
    from . import conf
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/imagekit/conf.py", line 1, in <module>
    from appconf import AppConf
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/appconf/__init__.py", line 1, in <module>
    from .base import AppConf  # noqa
  File "/home/myuser/.virtualenvs/backend/local/lib/python2.7/site-packages/appconf/base.py", line 107
    class AppConf(metaclass=AppConfMetaClass):

I've an old project running in Python 2.7.16 and django==1.11.27.
If the issue is not occurring with non-deprecated versions of python/django feel free to close this.

Syntax error in Python2 for version 1.0.4

Hello, dear maintainers!

Recent release 1.0.4 broke the compatibility with Python2. How backward-incompatible changes can be minor version update, firstly?

Secondly, if these changes are not compatible with python2 due to syntax3-only changes, then the package should not be pushed to PyPy wheel as py2 supported.
You did push it like this: django_appconf-1.0.4-py2.py3-none-any.whl. It should be only py3 then.

We are having the following issue:

Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/home/user/venv/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "/home/user/venv/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 354, in execute
    django.setup()
  File "/home/user/venv/local/lib/python2.7/site-packages/django/__init__.py", line 21, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/home/user/venv/local/lib/python2.7/site-packages/django/apps/registry.py", line 85, in populate
    app_config = AppConfig.create(entry)
  File "/home/user/app/venv/local/lib/python2.7/site-packages/django/apps/config.py", line 87, in create
    module = import_module(entry)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/user/app/tracking/__init__.py", line 1, in <module>
    from receivers import *
  File "/home/user/app/tracking/receivers.py", line 17, in <module>
    from rss.models import RssFeed
  File "/home/user/app/rss/models.py", line 35, in <module>
    from object.models import Category
  File "/home/user/app/object/models/__init__.py", line 24, in <module>
    from django_fsm_log.models import StateLog
  File "/home/user/venv/local/lib/python2.7/site-packages/django_fsm_log/models.py", line 4, in <module>
    from django_fsm_log.conf import settings
  File "/home/user/venv/local/lib/python2.7/site-packages/django_fsm_log/conf.py", line 2, in <module>
    from appconf import AppConf
  File "/home/user/venv/local/lib/python2.7/site-packages/appconf/__init__.py", line 1, in <module>
    from .base import AppConf  # noqa
  File "/home/user/venv/local/lib/python2.7/site-packages/appconf/base.py", line 107
    class AppConf(metaclass=AppConfMetaClass):

I understand that Python2 is not supported anymore and it reached end on life. But a lot of companies are still using it, even in production. And changes like these are breaking things which expected to be working. We should not break anything, especially if we can easily avoid it.

Import `AppConf` using `AppConfig.ready()` hook

In docs, you mention that one should trigger the AppConf imports as soon as the Django starts. To do so, you suggest to import the conf modules from the app's models module.

``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.

I think that a much cleaner (?) solution (how are the models related to configuration, anyway?!) would be to do the import using the ready() hook of the app configuration class (put in the apps.py module).

For example, given an app polls with the conf submodule containing PollsConf(appconf.AppConf), one could go with:

import importlib
from contextlib import suppress

from django import apps


class PollsConfig(apps.AppConfig):
    name = "polls"
   
    def ready(self):
        super().ready()
        
        with suppress(ImportError):
            importlib.import_module(f"{self.name}.conf")
       
        # or simply
        # from . import conf
        # (this will make linters unhappy, though ...)

What do you think? Is it worth to be documented? I have recently used this approach and it works.

Private settings

Hi 👋🏻

I'd to share an idea for private settings, a new feature for the django-appconf.

Consider the following example:

class MyAppConf(AppConf):
    PUBLIC = ...
    
    _PRIVATE = ...

    class Meta:
        prefix = "my_app"

In the current implementation, PUBLIC and _PRIVATE are accessible fromdjango.conf.settings via MY_APP_PUBLIC, whereas MY_APP__PRIVATE. My idea is to make _PRIVATE inaccessible as it is considered to be private.

I see two ways we could implement this.

  1. Treat names prefixed with an underscore as private (as in the example above; this is Python's way...). However, the issue with this approach is that some linters may complain that other parts of the codebase use private attributes (e.g. Ruff, the rule SLF001).
  2. Add an extra attribute to Meta (private, let us say) that could be a list of names for private settings.
class MyAppConf(AppConf):
    PUBLIC = ...
    
    PRIVATE = ...

    class Meta:
        prefix = "my_app"
        private = ["private"]  # uppercase is implicit

This could be useful (and elegant/Pythonic IMHO) for adding configurations specific to the configured app. What's your opinion?

If you find this idea interesting, I can open a PR.

Python 2.7 compatibility bug in version 1.0.4

Version 1.0.4 introduces a Python 2.7 compatibility bug. AFAIK, django-appconf has not officially dropped Python 2.7 support. The PR that introduced the bug is #57. The bug is on line 107 of base.py, where the metaclass is declared. The Python 2.7 compatible code (using six) was replaced with code that only works in Python 3.

I have added PR #60 to fix it.

Update prefixing of names starting with underscore

Currently, all the names defined within AppConf are prefixed in the same way when accessed from django.conf.settings. For:

class MyAppConf(AppConf):
    PUBLIC_SETTING = ...
    
    _PRIVATE_SETTING = ...

    class Meta:
        prefix = "my_app"

PUBLIC_SETTING can be accessed by MY_APP_PUBLIC_SETTING , whereas _PRIVATE_SETTING goes as MY_APP__PRIVATE_SETTING.

I think that an alternative way for the second case would be to add an underscore before the full (i.e. prefixed by the AppConf.Meta prefix) name. So finally this would be: _MY_APP_PRIVATE_SETTING.

Why is this better? IMO, this preserves the "privacy" of the original AppConf attribute.

Alternatively underscore-prefixed settings can be set as inaccessible from the django.conf.settings (see #98).

AppConf ignores @override_settings decorator

I've simple conf.py

class RatesConf(AppConf):
    # Disabling this will be useful for testing purposes
    PREMIUM_AUTO_RECALCULATION_ENABLED = True

and I'm using

from conf import RatesConf

...
@receiver(quote_rates_data_changed)
def on_quote_rates_data_changed(signal, sender, quote, **kwargs):
    if RatesConf.PREMIUM_AUTO_RECALCULATION_ENABLED:
        ...

I set it to False for all tests except when I need to test this place. I'm trying to override it with django's override_settings decorator:

@override_settings(RATES_PREMIUM_AUTO_RECALCULATION_ENABLED=True)
class RatesSignalsTestCase(TestCase):
    def test_quote_rates_data_changed_signal_run_recalculation(self):
        print RatesConf.PREMIUM_AUTO_RECALCULATION_ENABLED 

And I'm getting False

keep unified versioning scheme

Hi! I'm packaging python-django-appconf for Arch Linux.
To be able to track this project's upstream it's very useful, if it provides a unified versioning scheme.
Currently there is versions with a prefixed v and those without. It would be good to stick to either or in the future. Thanks!

Document `configure_` functionality

The docs make no mention of the functionality for configuring settings, which is a pretty useful feature to be aware of.

I've seen this functionality used out in the wild, and have confirmed that it exists in codebase, but it cannot be found in the docs!

Why not just using settings.py ?

I am sorry for this simple question. I was trying to figure out the use case for django-appconf, and basically for now I don't see it doing something that is already done by declaring your own custom settings in settings.py and re-use it everywhere.

Could somebody please explain to me what problem it solves that settings.py doesn't?

README is unclear

It's not clear to me what "Add a settings.py to your app's models.py" means in the README. I'm assuming that a settings.py file with default settings for the app should be created alongside the app's models.py.

django-appconf-0.5 test glitches, build doc needs -j1

The tests from tunning appconf/tests/tests.py have the following 2 issues;

Issue 1. appconf/tests/tests.py requires
sed -e 's:from .models:from models:' -i appconf/tests/tests.py

In gentoo, an ebuild runs the install; run from an ebuild, from .models does NOT work.

Issue 2. The line 48;
prefix = model_module.name.split('.')[-2]

in appconf/base.py draws error in the test phase;

  • Testing of dev-python/django-appconf-0.5 with CPython 2.5...
    Traceback (most recent call last):
    File "appconf/tests/tests.py", line 5, in
    from models import (TestConf, PrefixConf, YetAnotherPrefixConf,
    File
    "/mnt/gen2/TmpDir/portage/dev-python/django-appconf-0.5/work/django-appconf-0.5/appconf/tests/models.py",
    line 10, in class TestConf(AppConf): File
    "/mnt/gen2/TmpDir/portage/dev-python/django-appconf-0.5/work/django-appconf-0.5/appconf/base.py",
    line 48, in new prefix = model_module.name.split('.')[-2]
    IndexError: list index out of range

    or python2.7

  • Testing of dev-python/django-appconf-0.5 with CPython 2.7...
    Traceback (most recent call last):
    File "appconf/tests/tests.py", line 5, in
    from models import (TestConf, PrefixConf, YetAnotherPrefixConf,
    File "/mnt/gen2/TmpDir/portage/dev-python/django-appconf-0.5/work/django-appconf-0.5/appconf/tests/models.py", line 10, in
    class TestConf(AppConf):
    File "/mnt/gen2/TmpDir/portage/dev-python/django-appconf-0.5/work/django-appconf-0.5/appconf/base.py", line 48, in new
    prefix = model_module.name.split('.')[-2]
    IndexError: list index out of range

When replaced with the value [-1]; it returns success for the test.
Your call whether the value -2 in the test is wrong, I'm not sure.

  1. An annoying glitch in build in the docs. Require emake -j1 -C docs pickle html
    in order to build with more than 1 option for emake, or make. Without -j; you get

Exception occurred:
File "/usr/lib64/python2.7/site-packages/sphinx/environment.py", line 1210, in get_doctree
doctree = pickle.load(f)
EOFError
The full traceback has been saved in /mnt/gen2/TmpDir/portage/dev-python/django-appconf-0.5/temp/sphinx-err-gT9rFC.log, if you want to report the issue to the developers.

Actually it is intermittent or inconsistent; i.e. sometimes it misfires, sometimes it gets thru
The setup in the Makefile is to build the docs with common to many other python packages.
It's actually a sphinx issue, but mentioning it here does no harm, and you could pass it on perhaps.

import_attribute depends on django.utils.importlib.import_module

which is no longer in Django master

Traceback (most recent call last):
  [...] irrelevance omitted
  File "/PATH/python3.3/site-packages/appconf/base.py", line 53, in __new__
    new_class.add_to_class('_meta', AppConfOptions(meta, prefix))
  File "/PATH/python3.3/site-packages/appconf/base.py", line 12, in __init__
    self.holder = import_attribute(self.holder_path)
  File "/PATH/python3.3/site-packages/appconf/utils.py", line 5, in import_attribute
    from django.utils.importlib import import_module
ImportError: No module named 'django.utils.importlib'

Version bump breaks pip install django-appconf

hey @jezdez,

I think that your version bump: a3e8adf has broken django-appconf installs. I made a new virtualenv and did a pip install django-appconf, and what I got was:

(melvin)[peterconerly@melvinsrevenge]$ pip install --ignore-installed django-appconf==0.6
Downloading/unpacking django-appconf==0.6
  Could not find a version that satisfies the requirement django-appconf==0.6 (from versions: 1.0.1, 1.0.1)
Cleaning up...
No distributions matching the version for django-appconf==0.6
Storing debug log for failure in /Users/peterconerly/.pip/pip.log

I would upgrade to 1.0.1, but pinax-theme-bootstrap requires ==0.6.

I think you just need to do some pypi massaging. Pip looks to pypi for 0.6, gets it, but then thinks that the version is 1.0.1.

No urgency! I've got a good version in another project from yesterday and I'll do a pip install -e or something. Enjoy your sunday.

Compatibility with diffsettings?

Hello,

I was nicely surprised to see that django apps using AppConf showed all their settings nicely in "manage.py diffsetting", imho that's a killer feature compared to all apps which hide their defaults in handmade "getattr(settings, x, default)" calls.

Maybe it'd be worth mentioning it in docs?

Would it be feasible to also make appconf inject default settings in "global_settings" of django, so that diffsettings also shows which app settings were overriden compare to their appconf defaults (with the "###")?

Error when used with django admin autodiscover

I see an error when celery_haystack is used with the django admin enabled, but I am filing it here because the error is specifically that the settings added by django-appconf aren't actually available on the settings object imported by "from django.conf import settings".

I am still trying to debug exactly what the issue is, but I see the following behavior when I have:
from django.contrib import admin
admin.autodiscover()
in my settings.py file and I try "python mange.py shell" (thus triggering the import of settings)

For reference, I am monitoring the settings object that is being written to by django/conf/init.py(82)setattr() and I am using:
Django==1.4.3
celery-haystack==0.7.2
-e git+https://github.com/toastdriven/django-haystack.git@2542426da5d75de458ec1c18f511648a328d62c6#egg=django_haystack-dev
django-appconf==0.6

I see that an initial settings object A is written to until the SETTINGS_MODULE environment var is read, at which point another settings object B is written to until the final celery haystack appconf setting (CELERY_HAYSTACK_COMMAND_APPS) is written, at which point the next call to setattr writes to object A again.

If I remove the call to admin.autodiscover() I see that A is written to until SETTINGS_MODULE, then B is written to, then the settings in B are written to A, then the celery haystack appconf settings are written to A.

If I remove the "from django.contrib import admin" line, I see everything written to A directly and everything works perfectly.

Test against Django 4.2a1

Per Carlton Gibson, I'd like to submit a PR to add Django 4.2 support. From what I can tell it is just updating tox.ini and verifying tests pass, let me know if there is more to do.

Help : How to add key-value pairs into the CACHES setting ?

I want to improve django-imagefit (https://github.com/davidfischer-ch/django-imagefit) to make it use appconf because at the moment this project overrides the value of CACHES (at least) !

Do you have an advice in what is the best way with appconf to set the default value for a key of CACHES e.g. CACHES ['imagefit'] = default_value ?

I founded this solution that seem too complicated for such a case : https://github.com/matthewwithanm/django-imagekit/blob/develop/imagekit/conf.py

Also another question, how do you'll implement this (line 42-44 of imagefit's conf.py) :

# ConditionalGetMiddleware is required for browser caching
if not 'django.middleware.http.ConditionalGetMiddleware' in settings.MIDDLEWARE_CLASSES:
    settings.MIDDLEWARE_CLASSES += ('django.middleware.http.ConditionalGetMiddleware',)

Thanks.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.