Move MiddlewareMixin out of utils.deprecation

[Jacob Walls]

Following some mastodon ​chatter kicked off by Farhan last fall, Carlton ​replied with an answer about why MiddlewareMixin lives under utils.deprecation:

I think it was meant to go away as we all moved to function based middleware. Then that never happened. Then MiddlewareMixin grew the async adaption two-step, and it’s useful for that. Even if we just use it internally, it should probably be moved. (Clean code and all that Jazz)

We have some +1s on that Mastodon thread, ending with "if a fellow picks it up", so here I am, proposing to move it :-)

We could choose to leave a single alias in utils.deprecation to avoid breaking changes for people explicitly importing MiddlewareMixin. It's a lot simpler than adding a release note or a deprecation path. (I might be in the minority with this view, though.)

[Carlton Gibson]

OK, yep. Nice hustle.

Deprecation could use a ​module level __getattr__ to raise the DeprecationWarning. 🤔

[CharulL00]

I’m claiming this ticket and will work on a patch.

[CharulL00]

I have opened a pull request for this ticket: ​https://github.com/django/django/pull/21519

The patch moves MiddlewareMixin out of django.utils.deprecation into the middleware package while keeping the old import path working for backward compatibility. I also updated the related imports, documentation, and added a test for backward compatibility.

[Mike Edmunds]

Replying to Carlton Gibson:

[...] Deprecation could use a ​module level __getattr__ to raise the DeprecationWarning. 🤔

It probably should. In the past, retaining multiple supported import paths to things that move has been considered a maintenance burden, and deprecating the old path was preferred. (Trying to remember the specific example where this came up.)