uv-build
A PEP 517 build backend provided by uv, implemented in Rust to accelerate building Python packages from source into wheels. It can replace traditional backends such as setuptools, hatchling, and flit.
Timeline (last 90 days)
uv-build is a PEP 517 build backend provided by uv, used to replace traditional build backends such as setuptools, hatchling, and flit, and is responsible for building source packages into wheels.
The poster's core concern is the ecosystem lock-in effect brought by uv-build: once an open-source library sets uv-build as its build backend, any user building that library from source must install uv.
Linux distribution maintainers usually build Python packages from source, and if a package's build backend is uv-build, the build environment must introduce uv and the Rust toolchain it depends on in advance, increasing packaging complexity and the burden of security auditing.
Those who support uv-build believe that the improvement in build speed is real, and that for large projects or CI environments it can significantly improve development efficiency.
Opponents believe that the build backend is not the main source of performance bottlenecks, and that for the vast majority of Python packages build time is mainly spent compiling C extensions or running tests rather than on the packaging logic itself, so the speed improvement brought by replacing setuptools with uv-build may be negligible in actual projects.
The net benefit brought by replacing setuptools with uv-build is almost negligible in projects that include extension compilation; only in pure Python scenarios with frequent rebuilds might the speed difference be perceptible.
A post titled "A plea not to use uv-build" sparked extensive discussion on Hacker News, in which the poster called on developers not to use uv-build as a build backend in their projects.
All Facts (7)
uv-build is a PEP 517 build backend provided by uv, used to replace traditional build backends such as setuptools, hatchling, and flit, and is responsible for building source packages into wheels.
50%UnverifiedThe poster's core concern is the ecosystem lock-in effect brought by uv-build: once an open-source library sets uv-build as its build backend, any user building that library from source must install uv.
50%UnverifiedLinux distribution maintainers usually build Python packages from source, and if a package's build backend is uv-build, the build environment must introduce uv and the Rust toolchain it depends on in advance, increasing packaging complexity and the burden of security auditing.
50%UnverifiedThose who support uv-build believe that the improvement in build speed is real, and that for large projects or CI environments it can significantly improve development efficiency.
50%UnverifiedOpponents believe that the build backend is not the main source of performance bottlenecks, and that for the vast majority of Python packages build time is mainly spent compiling C extensions or running tests rather than on the packaging logic itself, so the speed improvement brought by replacing setuptools with uv-build may be negligible in actual projects.
50%UnverifiedThe net benefit brought by replacing setuptools with uv-build is almost negligible in projects that include extension compilation; only in pure Python scenarios with frequent rebuilds might the speed difference be perceptible.
50%UnverifiedA post titled "A plea not to use uv-build" sparked extensive discussion on Hacker News, in which the poster called on developers not to use uv-build as a build backend in their projects.
50%