Open freakboy3742 opened 1 day ago
Just wanted to pop a note in here that I'm keen to work on this issue. @freakboy3742, do you envision this happening as first a transition to httpx's synchronous APIs, and then only later refactors to the asynchronous API if necessary? So far as I can tell, requests is currently used by Briefcase for file downloads and a test utility, neither of which would benefit much (maybe at all?) from an async refactor and all that it would entail.
Honestly - I don't think Briefcase will ever have much use for the async APIs. There's very little that Briefcase does that could be performed asynchronously, other than maybe downloading multiple files at the same time; but given the frequency with which that happens, and the time those downloads take, I don't think we'd actually gain much from the complexity it would add.
The benefit to Briefcase is mostly (a) consistency - the BeeWare tutorial already uses httpx, specifically because it does need the async APIs; and (b) the social signal of increasing httpx's download count and reducing requests's download count, as part of the broader movement to encourage people to move away from requests as the "go to" Python HTTP API.
What is the problem or limitation you are having?
Briefcase currently uses the
requests
library to manage downloads etc. Requests is a well known quantity in the Python ecosystem, but it contains some architectural dead ends that prevent it from adapting to modern web and Python standards.Describe the solution you'd like
We should replace the use of
requests
in the Briefcase codebase withhttpx
. The two share very similar APIs; but httpx has features and benefits that requests doesn't have (and, in some cases, can't have without a major rewrite), including:Describe alternatives you've considered
Do nothing. Requests definitely works as-is. We could safely do nothing and Briefcase will keep working.
The other big
requests
alternatives library isaiohttp
; however, that's more of an 'async only' solution.Additional context
This isn't an urgent update. It's more of a "future-proofing" thing. There's also the benefit of using BeeWare's position to send a social signal that despite
requests
being a well-known and entrenched solution for HTTP management in Python, it's not the only solution, and in many cases, it's not the best solution.