Changes between Initial Version and Version 2 of Ticket #28752
- Timestamp:
- Oct 30, 2017, 12:29:55 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28752
- Property Summary Django.setup() should be idempotent → django.setup() should be idempotent
-
Ticket #28752 – Description
initial v2 1 Alas the ticket #27176 dealt only with the "apps.populate" part, but the whole setup() must be protected, else we'll always have weird side effects on duplicate calls. 1 2 2 I've been bitten numerous times by the impredictable behaviour of django when django.setup() was called numeroustimes.3 Here is a testcase showing the reset of the "django" logger level, for example, when calling setup() multiple times. 3 4 4 In the old days I had exceptions, now it's mainly subtle breakages of logging configuration.5 Depending on the exact LOGGING dict (with disable_existing_loggers etc.), even the shape of the logging tree might be changed. 5 6 6 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 problem. 7 {{{ 7 8 8 For example this ticket concerned script+importable modules : 9 https://code.djangoproject.com/ticket/26152 9 def test_duplicated_setup_calls(self): 10 import django, logging 11 #from django.conf import settings 12 #print(settings.LOGGING_CONFIG, settings.LOGGING) 13 14 django.setup() 15 logging.getLogger('django').setLevel(logging.DEBUG) 16 assert logging.getLogger('django').level == logging.DEBUG 10 17 11 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. 18 django.setup() 19 assert logging.getLogger('django').level == logging.DEBUG # raises 12 20 13 Would it be OK to make django.setup() idempotent, or even expose a "is_ready" flag for easier introspection ? 14 21 }}} 22