What to do with asgiref?

[Kludex]

django-channels uses asgiref, and uvicorn also uses asgiref (but only for typing). The mismatch on versions can cause issues, as regressions can happen on asgiref.

For that reason, I think we should remove asgiref as mandatory dependency from uvicorn. With that in mind, I'd like to propose solutions:

1. The first solution would be to use asgiref only at TYPE_CHECKING time. Implemented on Remove asgiref from minimal requirements #1460. I've implemented with __future__.annotations so we'd have less diff, but I can with string annotation.
2. Create the types on uvicorn itself. Implemented on Replace asgiref for native types #1476. Maybe needs to add the asgiref license (?).
3. Use a third party package that is independent of asgiref. Implemented on Replace asgiref by asgi-types #1515.

Of those three solutions, the second one is the one that I like more. Opinions? @euri10

Related: django/asgiref#333

[euri10]

I'b be for 3, so that it is reusable across other libraries, but tbh I don't mind having asgiref as a dependency, it's the de facto standard,

[Kludex]

I forgot to link the issue... #1305

[tomchristie]

Wrt. (1) I don't think the package would need to be in extra_requirements - instead include it in the repo requirements.txt, same as other testing requirements.

It shouldn't be needed by dependants of uvicorn, as at that point it's only used by our test tooling. (Right?)

If you want to have typeddict level type checking of the ASGI spec, then that seems like a pretty decent approach to me. You get the strict type checking, without introducing another potential package versioning clash.

Personally I think there's also a perfectly reasonable case to make that type checking at that level potentially introduces more work than the benefit it provides. So I think it's also pretty okay to just have a more minimal ASGI type checking, that doesn't go down to the level of typing out the scope and messages. If I was going to go with (2) then personally that's the level of type checking I'd go with. But I'm not super involved here, so I don't think my opinion needs too much weight. Just a perspective worth sharing.

[Kludex]

@tomchristie Your opinion is always wanted and valuable. 🙏

Wrt. (1) I don't think the package would need to be in extra_requirements - instead include it in the repo requirements.txt, same as other testing requirements.

That also works for me. 👍

It shouldn't be needed by dependants of uvicorn, as at that point it's only used by our test tooling. (Right?)

Well... If installed in the venv, people would be able to follow references in code, I guess?

Personally I think there's also a perfectly reasonable case to make that type checking at that level potentially introduces more work than the benefit it provides.

Given the bugs found over the year (well, they were not that impactful, otherwise we'd have noticed... But there were some of them. I don't have statistics tho...) I think it was good to do this. Now that we are almost at the end of fully annotating, I don't think it would be good to lose the strictness there. 🤔

[tomchristie]

I think it was good to do this.

Fair.

Then from my perspective (1) looks good, but with the amendments mentioned. Provides the benefits of us type checking our source code, without requiring the dependency for runtime users of uvicorn.

[Kludex]

We have removed asgiref as dependency on #1532.

Thanks everybody 🙏