开发者呼吁勿用 uv-build 作为 Python 构建后端

一位代表 Gentoo 用户社区的开发者在 Hacker News 上发声，建议不要采用 uv-build 作为 Python 构建后端1。该开发者指出 uv-build 存在多方面问题，其中包括体积过大、频繁更新和跨平台支持不足。

uv-build wheels 的体积为 1.2-1.5 MiB（依平台而异，版本 0.13.0），远超替代方案 flit-core 的 45 KiB1。这种体积差异对于需要从源代码编译的 Gentoo 用户造成了实际负担。uv 在 30 天内发布了 12 个版本，导致 Gentoo 用户需要频繁重新编译1。此外，由于 uv 采用 Rust 编写，其平台支持存在局限，包括在特定包中出现 bug（如 rustix::fs 跳过 SPARC 架构），以及在 32 位平台上存在地址空间溢出问题1。

该开发者认为，uv-build 所宣称的性能优势仅约 100 毫秒，不足以抵消其带来的构建时间成本1。鉴于 PEP 517 允许任何前端与任何后端组合，flit-core 和 hatchling 等替代方案完全可行1。

A developer representing Gentoo users has raised concerns about the adoption of uv-build as a Python package build backend, citing significant practical drawbacks that outweigh its performance benefits 1.

The primary objection centers on uv-build's substantial size and rapid release cycle. The compiled wheels for uv-build measure between 1.2 and 1.5 MiB depending on the platform (version 0.13.0), vastly exceeding alternatives like flit-core at 45 KiB 1. With the uv project releasing 12 versions within a 30-day period, Gentoo users who build packages from source face frequent recompilation burdens 1. The developer argues that the marginal performance improvement—roughly 100 milliseconds—does not justify these compilation costs 1.

Platform compatibility presents another significant barrier. The underlying Rust language has limited architecture support, with documented issues such as rustix::fs skipping SPARC architecture and address space overflow problems on 32-bit platforms 1. The developer notes that PEP 517 standards allow flexible combinations of frontends and backends, making alternatives like flit-core and hatchling viable substitutes for projects currently considering uv-build 1.