Allow running custom logic in django.setup().

[pascal chambon]

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.

[pascal chambon]

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 ?

[Carlton Gibson]

Hi Pascal. I'm going to close this as a Duplicate of #28752. Let's keep the discussion there. Thanks.

[Carlton Gibson]

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.

[Carlton Gibson]

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

[pascal chambon]

Ok the PR is pending for #28752 B-)

[Florian Apolloner]

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?

[Carlton Gibson]

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.