#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
--------------------------------+--------------------------------------
Changes (by Tim Graham):
* cc: Aymeric Augustin (added)
Old description:
> I've been bitten numerous times by the impredictable behaviour of django
> when django.setup() was called numerous times.
>
> In the old days I had exceptions, now it's mainly subtle breakages of
> logging configuration.
>
> 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.
>
> For example this ticket concerned script+importable modules :
> https://code.djangoproject.com/ticket/26152
>
> 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.
>
> Would it be OK to make django.setup() idempotent, or even expose a
> "is_ready" flag for easier introspection ?
>
> -- here are some updates, comments get rejected as spam --
>
>
> 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().
New description:
I've been bitten numerous times by the impredictable behaviour of django
when django.setup() was called numerous times.
In the old days I had exceptions, now it's mainly subtle breakages of
logging configuration.
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.
For example #26152 concerned script+importable modules.
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.
Would it be OK to make django.setup() idempotent, or even expose an
"is_ready" flag for easier introspection ?
-- here are some updates, comments get rejected as spam --
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().
--
Comment:
Aymeric, any input?
--
Ticket URL: <https://code.djangoproject.com/ticket/28752#comment:8>
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.6ea71d2e9b8faa73d3eefe7b47657f27%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
