Opened 7 years ago
Last modified 5 years ago
#28752 closed Cleanup/optimization
django.setup() should be idempotent — at Version 4
Reported by: | pascal chambon | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | 1.11 |
Severity: | Normal | Keywords: | |
Cc: | Aymeric Augustin | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Calling django.setup() multiple times is useless, BUT it can happen in lots of cases, that's why imho this case should be handled by the framework to avoid nasty side effects.
These "duplicate calls" often involve the collision between manage.py commands, tests, custom scripts, and external launchers like pytest-django. Plus maybe some corner cases when unittest-style TestCases and pytest-style test functions are mixed in the same project.
Users have to do a real gym to call setup() "at some moment" in all these use cases, yet try to prevent multiple calls of this initialization step (like the 'ifname == "main"' protection). So far my only way out was often to check for (not really undocumented) states of the framework before calling setup().
Change History (4)
comment:1 by , 7 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Summary: | Django.setup() should be idempotent → django.setup() should be idempotent |
comment:2 by , 7 years ago
Description: | modified (diff) |
---|---|
Resolution: | duplicate |
Status: | closed → new |
comment:3 by , 7 years ago
Thanks. Can you explain the use case for calling django.setup()
multiple times?
comment:4 by , 7 years ago
Description: | modified (diff) |
---|
I believe this is addressed in Django 2.0 by #27176. If not, please reopen with a minimal project that reproduces the problem you're encountering.