在看到又有十多个软件包因一个关键依赖切换到 uv-build 而在 Gentoo 上失去关键词后，我想代表 Gentoo 用户提出请求：请不要将 uv-build 作为构建后端。为了明确，这并不是针对 uv 本身或其他 Astral 工具；这些工具非常优秀且上游反应迅速。uv-build 后端是我们必须反对的一件事。我并不是说它不好；我只是说它的好处没有超过缺点。缺点是什么呢？它非常庞大，并且是用 Rust 编写的。Rust 有许多优点，但对用来构建纯 Python 软件包的构建后端来说，这些优点并不重要。它是一个巨大的依赖项（截至 0.13.0，视平台而定，它的 wheel 大小在 1.2 MiB 和 1.5 MiB 之间），而且与使用小型纯 Python 后端（比如 flit-core，wheel 大小为 45 KiB）相比没有任何好处。这意味着所有 Gentoo 用户都需要从源代码构建它，并且考虑到它发布的频率相当高（在撰写这篇文章的前 30 天内发布了 12 个版本），这需要花费大量的构建时间。也就是说，对于每 100 毫秒花在运行 uv-build 来安装一个版本的时间，Gentoo 用户将花费很多小时一遍又一遍地构建新的 uv-build 版本。然而，构建时间并不是最大的问题；可移植性才是。你几乎可以在任何可以获得工作 C 编译器的地方运行 Python。某些小功能可能无法工作，但核心是相对可移植的。Rust 支持的平台列表在缓慢增长，即使你能在某个平台上获得一个工作正常的 Rust 编译器，uv 也可能无法工作。问题可能从 uv 依赖的很多软件包中的错误（例如，rustix::fs 及其依赖项跳过 SPARC，理由不明）到可执行文件变得太大，以至于工具链耗尽地址空间（与系统内存不同，你无法真正地为系统添加地址空间；Gentoo uv ebuild 已经带有两个黑客，以使其可以在 32 位平台上构建 uv）。然后，如果你的平台根本不被支持……好吧，我们只想说，添加和维护一个新平台是一份全职工作，可能会涉及到大量对代码变动的咒骂。至于优点呢？好吧，我知道两个使用 uv-build 的理由。第一个是与你的项目使用 uv 的一致性，但这并不重要。这是一个后端，PEP 517 的整个意义在于你可以使用任何后端与任何工具配合。你可以使用 flit-core，也可以使用 hatchling，这两者都可以与 uv（或任何其他前端）正常工作。另一个理由是性能，但这一点的论点更没有意义。即使重要，我们实质上所说的也是一个大约 100 毫秒的差异，用于一次很少执行的操作；同样可能的是，任何收益都会被下载 1.5 MiB 的 uv-build wheel 所需的时间所抵消。但这并不重要，因为实际上这个后端只被项目开发者、贡献者、CI/CD 工作流、下游打包者和源分发的用户所使用；所有普通用户只使用 wheel。在这些群体中，源分发用户群是最大且受影响最深的群体，任何性能的提升都被构建 uv-build 所花费的时间所抵消。