settings.configure has undocumented differences from using a settings module

[Carl Meyer]

Calling django.conf.settings.configure bypasses the Settings class in that module entirely (in favor of UserSettingsHolder), thereby bypassing all of Settings.init. This makes it subtly but occasionally critically different: globs in INSTALLED_APPS are not processed, the os.environ timezone is not set, and there is no friendly string-conversion-to-tuple for settings like TEMPLATE_DIRS.

Not setting os.environ timezone is ​documented and correct: settings.configure implies that you are in control of your environment and may be using Django as a piece of a larger system, Django should not go messing with the environment.

The other two differences are oversights and should be fixed.

[Carl Meyer]

Correcting summary and marking Accepted per discussion with Malcolm at sprint.

[Gary Wilson]

A patch that refactors the Settings classes a bit, gets rid of the need for a BaseSettings class, and makes it so that the UserSettingsHolder class uses the same code paths for some post-processing of settings.

[Jannis Leidel]

Please don't call the method initialize but load (or similar), the ambiguity to __init__ is odd. Other than that this looks good to me.

[Matt McDonald]

Both the INSTALLED_APPS globs and string-to-tuple conversion have been deprecated, but calling configure() now also doesn't properly initialize the logging configuration from the settings LOGGING and LOGGING_CONFIG values. This can be fixed with a simple patch, which I've attached.

[Claude Paroz <claude@…>]

In 34162698cc7a3c75b1d1b2e18b481aa7e865dc98:

Fixed #14264 -- Ensured settings.configure configures logging

Thanks Matt McDonald for the patch.

[Claude Paroz <claude@…>]

In e6bc0c5babe97af86679ef7fe4f5975eb86f532f:

[1.5.x] Fixed #14264 -- Ensured settings.configure configures logging

Thanks Matt McDonald for the patch.
Backport of 34162698c from master.

[Claude Paroz]

#18316 was a duplicate