Why I forked httpx
Yesterday I forked httpx. The new fork is called httpxyz.
Reasons for the fork
HTTPX is a very popular HTTP client for Python. There is lots of code depending on it.
In 2024, I contributed zstd content decoding. This got merged and released! I was very happy and proud. Then I found out it was broken. I contributed a fix. The fix was ignored and there was never any release since November 2024. Me, and others, asked repeatedly for a release containing my fix. I sent email to the author personally. I got response when I added that I was considering forking. The author replied “1.0 development is on course”. Which is probably true but it has been in the planning for over two years now ref. Even the ‘patch level’ release for 0.28.2 has been in draft for over a year.
And apart from this, there’s:
- Recently issues have been made hidden on the github repository, and discussions have been turned off. Having issues hidden makes it more difficult for people to contribute to the package but also to use the package since issues are linked all over in code and documentation also. See reddit thread
- There has been talk about an upcoming 1.0 release for years now, back to 2020 or so. In a discussion from October 2024, it was laid out that the 1.0 might look very different than the current version of httpx. Simon Willison added his points eloquently, please read them.
- Probably as a result, both openai and anthropic python packages, that depend on httpx, have put guards in their pyproject.toml to not install version 1.0.
- The author previously added breaking changes in minor updates, causing churn
for many people, stating “The
httpxpackage is not yet at a 1.0 SEMVER release” ref. It’s pre-1.0, that is right, but if so many people use your package a bit more consideration for compatibility seems in place. - The author also created Django REST framework, and turned off issues and discussions there, a little over a year ago. This made life for people using the product more difficult ref
- The author also created MkDocs, of which an interesting blog post was published recently. Some patterns seem to be recurring.
All this together made me think creating a fork is the best way forward, to provide a stable path for people invested in httpx.
I do understand about maintainer burnout, and preferring to work on ‘next’, and that there is life outside of Python, but I think not doing anything for maintenance and also not letting other people help out in maintaining, for such a high profile module, is problematic.
I do hope that Kim will go on to make much more beautiful software and that there will be a HTTPX2 that will be excellent!
FAQ
Q: Why did you fork?
See all the reasons above
Q: So what is the plan now?
Maintain a stable fork of httpx. No great rewrites, no breaking changes, no big changes to the project setup (for now). The motto is: Move a little faster and not break things.
Q: But are you not also going to burn out? Surely it’s lots of work
There has been no release since 2024 for httpx. A little more frequent would go a long way. My buddy Sander Wegter is a co-maintainer to spread the load.
Q: Should I port all my code now?
If you want, you’d be welcome. But if everything just works for you now, I’m not sure it’s warranted. The idea is that there is a path for you if you need it.
Q: but what about plugins?
That’s a fair point. If you’d use import httpxyz as httpx, many things will
just work but some more intricate setups and/or plugins and extensions might
not. We’ll have to see if they are going to be adjusted.
Thanks, and have fun!