Forking httpx as httpxyz
39 points by jmillikin
39 points by jmillikin
This is somewhat related to The Slow Collapse of MkDocs, which was discussed a few days back. It sounds like the Slow Collapse post triggered the fork because it's the only reason listed that's completely new.
https://github.com/jawah/niquests was mentioned on the orange site as a great alternative to requests/httpx, and the benchmarking claims seem impressive. It's a fork of requests but with added async, HTTP/2 and HTTP/3 support (plus more).
It appears to mainly be done by one person, including the underlying dependencies (urllib3, h2, aioquic), which I guess is where some of the room for performance optimisations comes from. It does, however, make me wonder how viable an alternative it is if it all relies on one person.
I guess it's not much better with the alternatives that also seem to hinge on single individuals, some of whom seem rather burnt out anyway.
It's also mentioned in the FAQ section of the linked article. (Might have been added after you read it)
Interesting that Michiel chose host the code for httpxyz on codeberg rather than github. I can't fault them for not choosing github during their one 9 of availability phase, but this does lead to some problems.
I can't evaluate popularity or adoption of httpxyz as a proxy for its stability and desirability as migration target. On github, I can see 15.2k stars, 568,238 repositories, and 27,833 packages as dependents for httpx. For codeberg, I can see none of that, so I can compare the trajectories of the two forks.
On github, I can see 15.2k stars, 568,238 repositories, and 27,833 packages as dependents for httpx. For codeberg, I can see none of that [...]
IMO this kind of visibility is a key driver bringing projects to github. Maybe there should be some kind of aggregator that collects relevant metrics (number of dependents, number of downloads, etc.) so projects can be compared across platforms.