settings.configure has undocumented differences from using a settings module
|Reported by:||Carl Meyer||Owned by:||Gary Wilson|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||yes|
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.
Change History (13)
comment:1 Changed 6 years ago by
|Summary:||settings.configure not equivalent to using a settings module → settings.configure has undocumented differences from using a settings module|
|Triage Stage:||Unreviewed → Accepted|
comment:3 Changed 5 years ago by
|Owner:||changed from nobody to Gary Wilson|
|Status:||new → assigned|