Developers Urge Against Using uv-build: An Analysis of the Reasons Behind It

Python's packaging ecosystem has undergone rapid iteration in recent years, and uv, the high-performance tool from the Astral team, has attracted significant attention for its extremely fast resolution and installation speeds. However, dissenting voices have emerged in the community—a post titled "A plea not to use uv-build" sparked extensive discussion on Hacker News, in which the author explicitly calls on developers not to use uv-build as a build backend in their projects.

What Exactly Is uv-build

To understand this controversy, we first need to clarify uv-build's position in the toolchain. uv itself is a package manager whose functionality covers dependency resolution, virtual environment management, and package installation. uv-build, meanwhile, is the build backend provided by uv, intended to replace traditional PEP 517 build backends such as setuptools, hatchling, and flit.

In other words, when a Python package needs to be built from source (for example, when pip install installs an sdist), the build backend is responsible for executing hooks such as build_wheel to package the source into a wheel. uv-build attempts to accelerate this process using a high-performance Rust implementation.

The problem is that choosing a build backend is not as free as choosing a package manager—it is written into the project's pyproject.toml and affects every user who installs the package from source.

PEP 517 and the Build Backend Mechanism

PEP 517 is a key standard in the Python packaging ecosystem, defining the build process and interface specification from source distributions (sdist) to wheels. Before PEP 517, tools such as pip invoked setup.py by default, relying on setuptools' implicit behavior, with no unified standard. PEP 517 introduced the abstraction of a "build backend": projects declare build-backend and requires in the [build-system] table of pyproject.toml, and installation tools install build dependencies in an isolated environment accordingly and invoke standard hooks such as build_wheel and build_sdist. PEP 518 supplements this by specifying pyproject.toml as the configuration file for the build system. This system allows multiple backends—including setuptools, hatchling, flit, poetry-core, and meson-python—to coexist without users needing to care about the underlying implementation. Precisely for this reason, the choice of build backend shifts from a personal preference into part of a project's external contract—it determines what toolchain anyone building the package from source must have in place.

The Core Controversy: Lock-in Effects and Ecosystem Fragmentation

The author's core concern is not uv-build's performance or quality, but the ecosystem lock-in effect it creates. Once an open-source library sets uv-build as its build backend, any user who wants to build the library from source must install uv. This stands in stark contrast to traditional backends such as setuptools, which are almost always present by default in Python environments and require no additional installation.

For downstream distribution maintainers, this problem is especially acute. Linux distribution packagers (such as maintainers for Debian and Fedora) typically need to build Python packages from source and maintain strict control over build dependencies. Introducing uv-build means their build environments must additionally incorporate the Rust toolchain and uv itself, increasing packaging complexity and the audit surface.

Such concerns are not without precedent. The Python packaging ecosystem has suffered in the past from build backend fragmentation, and the community expended considerable effort to establish a unified build interface standard through PEP 517/PEP 518.

How Linux Distributions Package Python Packages

Maintainers of Linux distributions such as Debian, Fedora, and Arch typically follow the principle of "build everything from source" rather than directly using wheels from PyPI. Reasons include: the need to adapt to the distribution's own Python version, compiler flags, security patches, and dependency policies; the need to ensure binaries are reproducible and auditable; and compliance with the distribution's strict restrictions on dependency sources (using only packages within the distribution's repositories). In practice, maintainers write packaging recipes (such as Debian's debian/rules or Fedora's spec files) and perform the sdist-to-wheel conversion in a controlled build environment. If a package's build backend is uv-build, it means that build environment must pre-install uv and the Rust toolchain it depends on—an extra burden in a distribution build system predominantly based on C/C++, and one that also triggers security audits for the new dependency. This is precisely why downstream maintainers are especially sensitive to build backend changes.

Is the Performance Gain Worth the Cost

Those who support uv-build argue that the build speed improvement is real. For large projects or CI environments, shorter build times can significantly boost development efficiency. The uv team's investment in tool performance is evident to all, and uv's performance in package resolution speed has already demonstrated the advantages of a Rust implementation.

But opponents raise a key question: the build backend is not the main source of performance bottlenecks. For the vast majority of Python packages, build time is spent primarily on compiling C extensions or running tests, not on the packaging logic itself. The speed improvement from replacing setuptools with uv-build may be negligible in real projects.

This asymmetry of "limited gain, clear cost" is the author's core reason for calling on the community to treat uv-build with caution.

The Real Distribution of Python Package Build Time

A common misconception is that "the packaging logic itself is slow." In reality, for pure Python packages, the build_wheel hook mostly just copies files, generates metadata, and compresses them into a zip, typically taking milliseconds to hundreds of milliseconds. What truly slows down builds falls into several categories: compiling C/C++/Rust/Fortran extensions (such as NumPy, Cryptography, Pillow, etc.), which often takes minutes; downloading and installing build-time dependencies; and running code generation or protocol compilation steps. setuptools does have performance issues with metadata and dependency discovery in large projects, but such bottlenecks can usually be mitigated through caching, parallel compilation, or switching to a lighter backend. Therefore, the net benefit of replacing setuptools with uv-build is almost negligible in projects that involve extension compilation; only in pure Python scenarios with frequent rebuilds might the speed difference be perceptible. When evaluating a build backend, one should first identify the project's real bottleneck rather than defaulting to "faster is better."

Practical Advice for Open-Source Maintainers

This discussion reflects a deeper tension in the Python community: how to balance tool innovation with ecosystem compatibility. For maintainers of open-source libraries, there are several pragmatic dimensions to consider:

If your library is mainly installed by end users via wheels, the choice of build backend barely matters, because most users will not build from source. But if your library is packaged by downstream distributions or referenced by other libraries as a build dependency, then the choice of build backend takes on a public character and requires more caution.

Another point worth noting is the build backend's stability commitment. As a relatively young tool, whether uv's API and behavior stability can meet the needs of long-term maintained open-source projects is a risk maintainers need to assess.

The community discussion ultimately points to a consensus: there is tension between freedom of tool choice and ecosystem responsibility. uv's success as a package manager should not automatically extend to the build backend domain, and developers need to make judgments based on their project's actual audience and distribution scenarios rather than blindly following tool trends.

This debate also reminds us that every technical choice in the Python packaging ecosystem is not merely a matter of personal preference, but a vote on the entire community's infrastructure.

One-line Summary

uv-build as a build backend has sparked community controversy, centered on limited performance gains that come with ecosystem lock-in and packaging burdens.

Paragraph Summary

The article centers on the Hacker News discussion "A plea not to use uv-build," analyzing why the build backend provided by uv should not be readily adopted in open-source projects. uv-build is uv's implementation intended to replace PEP 517 backends such as setuptools; once written into pyproject.toml, it affects all users who build the package from source, forcing them to install uv and the Rust toolchain. For downstream distribution maintainers such as Debian and Fedora, this significantly increases packaging complexity and the audit surface. Supporters emphasize the value of build acceleration, but opponents point out that the build backend is usually not the performance bottleneck, with real time spent on compiling extensions or running tests. The article concludes by advising maintainers to judge based on their project's audience: if installed by end users as wheels, the impact is minimal; if packaged by downstream distributions or referenced as a build dependency, the choice of build backend takes on a public character and requires careful assessment of stability and ecosystem responsibility.