Use of new Settings.is_overridden() method breaks if settings.configure() is used

[Carl Meyer]

There are two ways to set up Django's settings; one is by passing a settings module to the Settings class, and the other is to call django.conf.settings.configure() with keyword arguments.

In d818e0c9b2b88276cc499974f9eee893170bf0a8 (the new checks framework) a new is_overridden method was added to Settings, and in the "check_1_6_compatibility" check, it is called on django.conf.settings. But if settings.configure() was used, django.conf.settings is not wrapping a Settings instance, it is wrapping a UserSettingsHolder instance. And thus the "check_1_6_compatibility" check dies with "AttributeError: 'module' object has no attribute 'is_overridden'".

[Carl Meyer]

Sorry, my description of the problem was incomplete. UserSettingsHolder does have an implementation of is_overridden(); the problem is that it tries to call self.default_settings.is_overridden(), and if settings.configure() was used, self.default_settings is simply the module object django.conf.global_settings, which obviously has no is_overridden method. Thus the error.

[Russell Keith-Magee]

First thought at a fix - either:

1) Add a try/except on the attempt to access the is_overridden property in UserSettingsHolder

2) Add an is_overridden method to global_settings.

I'd prefer (1) so we can keep global_setings clean, but I'm open to other suggestions.

[Carl Meyer]

Here's my proposed fix: ​https://github.com/django/django/pull/2188

In addition to fixing this bug and adding tests for is_overridden(), it also changes the semantics of UserSettingsHolder.is_overridden, but I don't think the previous semantics made sense: they ignored any setting that was explicitly set on the UserSettingsHolder, and they considered deletion of a setting to not be an override.

[Carl Meyer <carl@…>]

In 6070a5d6a6950bdbd93853c4b1636c7eec820b20:

Fixes #21833 -- Fix UserSettingsHolder.is_overridden() and add tests.