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:1 by pascal chambon, 6 years ago

Pending PR on ​https://github.com/django/django/pull/11435.

Version 0, edited 6 years ago by pascal chambon (next)

comment:2 by Carlton Gibson, 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 Carlton Gibson, 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.

comment:4 by Carlton Gibson, 6 years ago

Triage Stage: Unreviewed → Accepted

OK, I'm going to provisionally accept this.

Two use-cases seem desirable:

  1. The testing example, of setting up mocks etc.
  2. 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:5 by pascal chambon, 6 years ago

Ok the PR is pending for #28752 B-)

in reply to:  4 comment:6 by Florian Apolloner, 5 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 Carlton Gibson, 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.

Note: See TracTickets for help on using tickets.
Back to Top