Changes between Version 2 and Version 4 of Ticket #28752


Ignore:
Timestamp:
Oct 30, 2017, 2:30:22 PM (6 years ago)
Author:
pascal chambon
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #28752 – Description

    v2 v4  
    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.
     1Calling 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.
    22
    3 Here is a testcase showing the reset of the "django" logger level, for example, when calling setup() multiple times.
     3These "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.
    44
    5 Depending on the exact LOGGING dict (with disable_existing_loggers etc.), even the shape of the logging tree might be changed.
     5Users 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().
    66
    7 {{{
    8 
    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
    17 
    18         django.setup()
    19         assert logging.getLogger('django').level == logging.DEBUG  # raises
    20 
    21 }}}
    22 
Back to Top