AppConf subclass settings disappear in second and subsequent uses of override_settings

[mhl]

(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'

[hellysmile]

I have absolutely same problem

[carltongibson]

OK. Thanks for the report. I'll have a look at this over the holiday period. (PRs welcome in the meantime.)

[sergei-maertens]

I'm running into this issue as well, what's the status of this ticket?

[carltongibson]

Unchanged. Root cause analyses or PRs welcome.

[sergei-maertens]

It seems that the root cause is that override_settings instantiates a django.conf.UserSettingsHolder, initialized with django.conf.settings._wrapped, causing the actual settings object no longer to be 'patched' with the django-appconf settings.

I'm seeing that override_settings does fire a setting_changed signal, so we might be able to hook into that. I'll get a proof of concept working and try to get back at you asap.

[sergei-maertens]

Update: root cause found, and it's actually documented in this project, and I quote:

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 issue at hand was caused by a templatetag for me as well. Since it's a library that doesn't have models, only a management command and a templatetag, the settings were loaded too late. So, when Django configures the override_settings object, it has never heard of your AppConf settings yet.

Because of the way that AppConf works, it's not targeting the correct object to add the settings to when it finally gets imported, leading to these errors.

The solution is very easy for this, you can use django's own AppConfig. Example:

# systemjs.apps
from __future__ import absolute_import, unicode_literals

from django.apps import AppConfig
from django.utils.translation import ugettext_lazy as _


class SystemJSConfig(AppConfig):
    name = 'systemjs'
    verbose_name = _('Django SystemJS')

    def ready(self):
        from . import conf  # noqa

Reference: https://docs.djangoproject.com/en/1.9/ref/applications/#for-application-authors

This ensures that the django default settings are patched by AppConf when starting up the tests, leading to @override_settings knowing of these settings before the patching starts.

I think this is only relevant for Django < 1.9, since the custom template tag libraries are loaded on startup time now, instead of when they're actually called in a template via {% load %}.

[carltongibson]

Good. Yes. And that all makes sense. I'm going to leave this open for now to remind me to have a think about it.

[sergei-maertens]

Might be interesting to build in an autodiscover feature just like the admin, and run it in the AppConfig.ready hook. Other than that, I think a small modification to the README should be enough (mention AppConfig).

[millerdev]

Also seeing the same issue here.