WSGI application loaded twice unexpectedly

[PeterJCLaw]

configurations.wsgi calls django.core.wsgi.get_wsgi_application, constructing an instance which is stored in an application variable locally. This doesn't seem to be documented and rather than using that instance, the recommended approach is to from configurations.wsgi import get_wsgi_application and then call that get_wsgi_application() to construct another instance. The same pattern is present in the ASGI file.

If a codebase has any side effects on the creation of Django's WSGI handler, which includes construction of all the middleware, then those side effects will be run more than once. This probably also impacts startup performance if there's anything heavyweight which happens during the construction of the handler.

We found this as we had configured telemetry instrumentation of middlewares to happen when the middlewares load (which I believe Datadog's Django instrumentation does too), which was unexpectedly running twice. For us that lead to each middleware being instrumented twice, creating weirdness in the traces.

I realise that side-effects in the construction of a WSGI handler maybe aren't the best thing to have, however I'd also argue that construction of a WSGI (or ASGI) handler as part of the import of what appears to be a utils file is kinda a side-effect and just as surprising.

I also realise that changing this is potentially a significant change (maybe even breaking for some users), so maybe it could be put behind a setting or something? Alternatively is there a reason that the docs prefer that consumers call the re-exported get_wsgi_application function rather than using the already created handler instance?