Opened 6 years ago
Closed 5 years ago
#30536 closed New feature (wontfix)
Allow running custom logic in django.setup().
Reported by: | pascal chambon | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Normal | Keywords: | setup |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Make django.setup() idempotent, and add setting DJANGO_SETUP_CALLABLE so that actual setup operations can be overridden in a project.
This is especially useful when testing, since test runners (eg. pytest-django) often configure the framework by themselves, before the end user can patch it with mockups and other early-time tweaks.
Change History (7)
comment:2 by , 6 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Hi Pascal. I'm going to close this as a Duplicate of #28752. Let's keep the discussion there. Thanks.
comment:3 by , 6 years ago
Patch needs improvement: | set |
---|---|
Resolution: | duplicate |
Status: | closed → new |
Summary: | Improve django.setup() semantic → Allow running custom logic in django.setup(). |
Looking at the PR, I've re-titled this reopened it, since I could see #28752 being accepted separately a resolution here. Can you please split the PR into two along those lines? Thanks.
follow-up: 6 comment:4 by , 6 years ago
Triage Stage: | Unreviewed → Accepted |
---|
OK, I'm going to provisionally accept this.
Two use-cases seem desirable:
- The testing example, of setting up mocks etc.
- If #28752 were in place, having a project-level hook for Do-this-Once setup logic might solve issues that app-level
ready()
handlers can't.
I'm not sure about the proposed implementation. I'll ask others to review.
(Maybe we have to say wontfix
, and stick with monkey patching setup()
if needs be...)
comment:6 by , 6 years ago
Replying to Carlton Gibson:
I'm not sure about the proposed implementation. I'll ask others to review.
Same here, my comment from the PR:
Personally I feel that this fix is happening at the wrong level. An environment variable (Or even as keyword argument to setup itself) feels more suitable, after all setup is the thing that reads your settings in the first place.
I think this might be something that could/should be discussed on the mailing list?
comment:7 by , 5 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Given #28752 and the concerns raised, I'm going to say wontfix
here.
It's easy enough to adjust an entry point script (canonically wsgi.py
, but whatever is in play) to run custom logic at start up.
IMO That's always going to come out cleaner than adding a settings powered hook in here.
Pending PR on https://github.com/django/django/pull/11435.
Note that the name "DJANGO_SETUP_CALLABLE" may not be optimal, but just "SETUP_CALLABLE" sounded waaaayyy too generic imho, since tons of things are setup in Django during initialization...
Maybe it'd be better to immediately call it DJANGO_SETUP_CALLABLES, and allow a list of dotted-strings too, since in the end there will surely be need for multiple presetups (eg mockups for django, mockups for a cms....), let's not force the user to define his own callable just to call several external setup funcs ? Why do people think about it ?