Why I forked httpx | Blog

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 httpx package 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!

Discussion on Hacker News