Changes between Version 4 and Version 5 of Ticket #28752


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

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #28752 – Description

    v4 v5  
    1 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.
     1I've been bitten numerous times by the impredictable behaviour of django
     2when django.setup() was called numerous times.
    23
    3 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.
     4In the old days I had exceptions, now it's mainly subtle breakages of
     5logging configuration.
    46
    5 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().
     7I couldn't find, in the issue tracker or the dev mailing list statements
     8about this subject, others than request from other users encountering the
     9problem.
    610
     11For example this ticket concerned script+importable modules :
     12https://code.djangoproject.com/ticket/26152
     13
     14The latest case in date for me is pytest-django having troubles with
     15these multiple setup() calls : https://github.com/pytest-dev/pytest-
     16django/issues/531 , due to multiple fixtures attempting this auto-setup.
     17
     18Would it be OK to make django.setup() idempotent, or even expose a
     19"is_ready" flag for easier introspection ?
     20
     21
Back to Top