Remove asgiref from minimal requirements

[Kludex]

This PR removes asgiref from the minimal requirements.

Changes:

• Leverage from __future__ import annotations to get a small diff - besides the collateral benefits.
• Move asgiref from minimal_requirements to extra_requirements.

[br3ndonland]

In general I think this looks fine, and I'm glad to see Uvicorn entering the __future__.

There's been a lot of discussion about lumping all the optional dependencies into uvicorn[standard] though, and asgiref isn't directly related to the other ones. Do we want to make people install all the optional dependencies just to do type checking? I'm not sure.

Related:

• Use optional package installs. #219
• About `uvicorn[standard]` #1274

[Kludex]

You have a good point. Then, are we against having it as optional but not on the standard extras? 🤔

[adriangb]

Is this worth it? I understand that Uvicorn wants to be minimal on dependencies, but I'm not sure the internal complexity with TYPE_CHECKING is worth it. I also agree that due to how the extras are currently specified it's problematic to ask users to install a bunch of dependencies just to get type checking, and in fact that is contrary to the goal of not forcing dependencies on users (granted, users could look into the extra and cherry pick what they want but that's quite a bit to ask and defeats the point of extras in the first place). Somewhat tangential, but I think this would be a good fit for a default-extras if it existed.

[adriangb]

This is quite a bit of boilerplate that we'll have to have in every module

[adriangb]

Given that this __future__ is in somewhat of a limbo, I would be reluctant to merge it.

[Kludex]

Is this worth it? I understand that Uvicorn wants to be minimal on dependencies, but I'm not sure the internal complexity with TYPE_CHECKING is worth it.

This is more for django-channel users than to be minimal (but also): #1305.

[Kludex]

• Let's discuss it first on What to do with `asgiref`? #1527