Gentoo Maintainer Urges Python Projects to Stop Using uv-Build Backend

The Appeal

Michał Górny, a Gentoo developer, has published a plea asking Python package maintainers not to use uv-build as a build backend. He emphasizes that the criticism is not directed at uv itself or other tools from Astral, which he describes as good tools with a nice and responsive upstream. The problem, he says, is specifically the uv-build backend, whose benefits do not outweigh its drawbacks for downstream distributions like Gentoo. He notes that yet another dozen Gentoo packages have already lost keywords because a single key dependency switched to uv-build.

Size and Build Burden

The main issue is that uv-build is large and written in Rust. As of version 0.13.0, its wheels range from 1.2 MiB to 1.5 MiB depending on the platform, compared to about 45 KiB for flit-core, a small pure Python backend. Because Gentoo builds packages from source, every user must compile uv-build, and the project releases quite frequently, with 12 releases in the 30 days before the post was written. Górny estimates that for every 100 ms spent running uv-build to install one release of a package, Gentoo users collectively spend many hours building new uv-build versions over and over again.

Portability Concerns

Górny argues that build times are not the biggest problem, portability is. Python can run pretty much anywhere a working C compiler exists, while the list of platforms supported by Rust is growing slowly. Even where a Rust compiler is available, uv may not work, due to problems ranging from bugs in dependencies such as rustix::fs and its dependencies skipping SPARC, to executables so large that the toolchain runs out of address space. The Gentoo uv ebuild already carries two hacks to make it possible to build uv on 32-bit platforms. For platforms that are not supported at all, adding and maintaining a new platform is described as a full-time job that may involve a lot of swearing at the code churn.

The Case for Alternatives

Górny acknowledges two arguments in favor of uv-build. The first is consistency with using uv for a project, which he dismisses because PEP 517 means any backend works with any frontend, so flit-core or hatchling will work just fine with uv or any other tool. The second is performance, which he says amounts to roughly 100 ms on an action executed rarely, and can equally be outweighed by the time needed to fetch the 1.5 MiB wheel. He adds that the backend is only used by project developers, contributors, CI/CD workflows, downstream packagers and users of source distributions, while all regular users use wheels instead. Of these groups, source distribution users are the largest and the most impacted, and any performance gain is defeated by the time spent building uv-build.

Sources: Lobsters