#28752: django.setup() should be idempotent
--------------------------------+--------------------------------------
     Reporter:  pascal chambon  |                    Owner:  nobody
         Type:  Bug             |                   Status:  new
    Component:  Core (Other)    |                  Version:  1.11
     Severity:  Normal          |               Resolution:
     Keywords:                  |             Triage Stage:  Unreviewed
    Has patch:  0               |      Needs documentation:  0
  Needs tests:  0               |  Patch needs improvement:  0
Easy pickings:  0               |                    UI/UX:  0
--------------------------------+--------------------------------------
Description changed by pascal chambon:

Old description:

> 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.
>
> Here is a testcase showing the reset of the "django" logger level, for
> example, when calling setup() multiple times.
>
> Depending on the exact LOGGING dict (with disable_existing_loggers etc.),
> even the shape of the logging tree might be changed.
>
> {{{
>
>     def test_duplicated_setup_calls(self):
>         import django, logging
>         #from django.conf import settings
>         #print(settings.LOGGING_CONFIG, settings.LOGGING)
>
>         django.setup()
>         logging.getLogger('django').setLevel(logging.DEBUG)
>         assert logging.getLogger('django').level == logging.DEBUG
>
>         django.setup()
>         assert logging.getLogger('django').level == logging.DEBUG  #
> raises
>
> }}}

New description:

 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 '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().

--

-- 
Ticket URL: <https://code.djangoproject.com/ticket/28752#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.6eb230d0d65a353f178a9eefeaedf05a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to