Why I forked httpx

Original Article ↗ Hacker News Discussion ↗

A fork of the popular Python HTTP client httpx has reignited concerns about maintainer burnout, stalled releases, and the risks of relying on a single, lightly maintained library for core infrastructure. Commenters debate whether forking is preferable to “joining forces,” highlight alternative clients like niquests and pyreqwest, and point to broader fragmentation in Python’s HTTP and packaging ecosystem. The thread also surfaces recurring tensions in open source: what, if anything, maintainers owe users when their projects become de facto standards, and whether foundations or the standard library should play a stronger stabilizing role.

Name Confusion and Initial Reactions

  • Multiple commenters initially confused httpx with htmx/htmlx, leading to misreading the article.
  • Some express nostalgia for the original httpx and disappointment it hasn’t become a stable, “v1” default HTTP client for Python.

Quality and Behavior of httpx

  • Some see httpx as promising but under-maintained, with long gaps between releases and ignored fixes.
  • Others are strongly critical: API seen as mediocre, performance and configurability as lacking, and maintainer behavior as risky for production (e.g., behavior changes or breakages without clear justification).
  • Specific complaints: thread-safety issues in production, no HTTP/3 support, awkward redirect defaults, and limited multiplexing.

Alternatives: niquests, aiohttp, pyreqwest, others

  • niquests gets repeated praise: perceived as much faster, better HTTP/2+ handling, closer to requests API, and smooth migration from httpx. Some companies report successful production switches.
  • aiohttp is praised as stable and well-established, but criticized for being HTTP/1‑centric and async-only.
  • pyreqwest is plugged as a high-performance client with an httpx compatibility layer and strong benchmarks.
  • Other tools/libraries (curl cffi, httpmorph, httpcloak, etc.) are mentioned in niche crawling contexts.

Forking, Governance, and Maintainer Burnout

  • Many argue that forking is appropriate when critical fixes aren’t released and maintainers block new maintainers while the project is widely depended on.
  • Others emphasize that open-source authors owe no obligations beyond the license; expectations of support or responsiveness are seen as entitlement.
  • A counterview holds that once a project becomes core infrastructure and takes sponsorship, there is at least a moral responsibility to delegate, transition, or communicate.
  • Suggestions include foundations or ecosystem support for key packages, and tools like modshim to layer fixes without full forks.

Python’s HTTP and Stdlib Gaps

  • Broad agreement that Python lacks a “friendly, async-ready, battle-tested” HTTP client in the standard library.
  • Fragmentation is seen as a consequence of HTTP complexity, async/HTTP2/HTTP3 demands, and reluctance to expand the stdlib after past “batteries included” pains.
  • Comparisons to other languages show that many also struggle with ergonomic, comprehensive HTTP clients.

Security, Naming, and Drama

  • Some worry the forked library could become a supply-chain target as it grows.
  • Mild concern about potentially confusing, near-identical naming vs. trademark issues; others note the name is generic and no clear trademark is evident.
  • Related project drama (around other Python HTTP/framework tools and MkDocs) is cited as part of a broader pattern of governance and interpersonal conflict in popular Python infrastructure.