Considering ASGI support

Opinions wanted…

The new SanicTestClient uses requests-async instead of aiohttp. In the past, we got around having aiohttp be a hard dependency by doing the import right inside the method.

I think we really have two options here: (1) we make requests-async a hard dependency of Sanic (and not just pip install sanic[test]; or (2) we break off testing.py into a new repo. That new repo would become an extra dependency. What are your thoughts? @core-devs?

My argument for making it a project on its own would be to continue to keep Sanic core as lean and dependency free as it can be in production.

a couple thoughts:

on size: The actual size of the dependency isn’t that bad, I run most of my stuff ontop of a docker image (jfloff/alpine-python:3.7) and pip install requests-async only costs 9mb (a 3% increase) in my image size

on experience: I think being able to test your application is a pretty core functionality, I lean towards keeping it as it keeps the developer experience better and especially if it makes contributor lives easier.

I think I lightly lean towards making it a hard dependency, especially to start if it keeps complexity down. We can always factor it out later if we find its strongly desired. That said if you think its a good point to start that testing repo and don’t think it will be that hard then by all means charge ahead.

1 Like

Worth keeping in mind too, that there’s still lots of work going on in the async HTTP client space that you’ll want to keep your eye on.

The requests-async package is the minimal amount of work that was needed to get an async equivelent of requests, but I’m still pushing hard towards maturing that all the way into a requests-compatible package that’s built from the ground up with either sync or async functionality, plus HTTP/2 support, a parallel requests API, test client adapter etc.etc.

Best place to keep up to date with progress there is probably this issue: https://github.com/encode/httpcore/issues/78

2 Likes