Changes between Version 6 and Version 8 of Ticket #28752
- Timestamp:
- Nov 1, 2017, 2:36:17 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28752
- Property Cc added
-
Ticket #28752 – Description
v6 v8 1 I've been bitten numerous times by the impredictable behaviour of django 2 when django.setup() was called numerous times. 1 I've been bitten numerous times by the impredictable behaviour of django when django.setup() was called numerous times. 3 2 4 In the old days I had exceptions, now it's mainly subtle breakages of 5 logging configuration. 3 In the old days I had exceptions, now it's mainly subtle breakages of logging configuration. 6 4 7 I couldn't find, in the issue tracker or the dev mailing list statements 8 about this subject, others than request from other users encountering the 5 I couldn't find, in the issue tracker or the dev mailing list statements about this subject, others than request from other users encountering the 9 6 problem. 10 7 11 For example this ticket concerned script+importable modules : 12 https://code.djangoproject.com/ticket/26152 8 For example #26152 concerned script+importable modules. 13 9 14 The latest case in date for me is pytest-django having troubles with 15 these multiple setup() calls : https://github.com/pytest-dev/pytest- 16 django/issues/531 , due to multiple fixtures attempting this auto-setup. 10 The latest case in date for me is pytest-django having troubles with these multiple setup() calls : https://github.com/pytest-dev/pytest-django/issues/531 , due to multiple fixtures attempting this auto-setup. 17 11 18 Would it be OK to make django.setup() idempotent, or even expose a 19 "is_ready" flag for easier introspection ? 20 12 Would it be OK to make django.setup() idempotent, or even expose an "is_ready" flag for easier introspection ? 21 13 22 14 -- here are some updates, comments get rejected as spam -- 23 24 25 15 26 16 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. … … 29 19 30 20 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 'if__name__ == "main"' protection). So far my only way out was often to check for (not really undocumented) states of the framework before calling setup(). 31 32 33