不要使用 uv-build 的请求
一个基于 Rust 的 Python 构建后端 uv-build 正在遭到 Gentoo 维护者的批评，他们认为其频繁发布和以二进制为主的分发模式，让一个源码驱动、可高度定制、且必须在用户机器上重建一切的发行版承受了很大压力。支持者则反驳说，Python 的打包标准、语义化版本，以及预构建的 manylinux wheels 对绝大多数开发者都很有效，而 Gentoo 可以调整自己的政策或锁定版本，而不是要求上游回避现代工具。技术细节背后，是一个更广泛的张力：究竟是优化主流平台与工作流，还是保留小众或遗留系统（如 32 位架构、SPARC 或 HP-UX）的可移植性与可用性。
Gentoo 与 uv-build：核心诉求
- Gentoo 几乎所有东西都从源码构建，并希望获得可复现、稳定的构建。
- uv-build 是一个基于 Rust 的 Python 构建后端，以二进制 wheel 形式分发，并且更新频繁。
- Gentoo 认为：
- 每次后端更新实际上都会迫使 uv-build 以及所有使用它的 Python 包重新构建。
- 这会带来很高的构建时间成本，尤其是在用户机器上，以及那些没有二进制可用的特殊架构上。
- 基于 Rust 的工具链会给遗留/冷门平台以及 32 位系统带来更高门槛，因为这些平台上可能没有 Rust 或 uv-build 可用。
版本、语义，以及“由谁决定”
- uv 一方的论点：
- Python 打包在接口层面是标准化的（PEP 517）；只要符合规范，后端就是可互换的。
- uv-build 默认使用 semver 范围；精确版本锁定是可选的，而重建频繁的真正原因在于这一点。
- 不对后端版本加约束，在技术上并不意味着“使用最新版本”；安装器可以自由复用任何已存在且兼容的版本。
- 反驳：
- Gentoo 和其他人认为，在实践中，新的 virtualenv 构建会拉取范围内的最新版本。
- 有人认为，对发行版来说，后端就是一个依赖；任何变更都应使构建失效，以保证可复现性。
- 对于 Gentoo 的“后端变化就重建”是否是 Python 标准要求，还是自设政策，存在争议。
源码 vs 二进制与性能
- 一些评论者表示，uv-build 基于 Rust 的快速实现和频繁更新，对于绝大多数安装二进制的用户来说并无问题。
- 另一些人认为，源码优先的发行版（Gentoo、NixOS 等）为重 Rust 的后端付出了不成比例的代价。
- 关于 Gentoo 的存在理由展开了争论：
- 批评者把“编译一切”称作“业余式的狂热”，并敦促改用二进制或类似 Nix 的缓存。
- 支持者则表示，Gentoo 的重点在于灵活性/控制力（USE flags、CPU 调优），而不只是追求性能最大化。
可移植性、Rust，以及长尾平台
- 有人担心，像 uv-build 这样的基于 Rust 的工具，以及 CPython 中潜在的 Rust 引入，会削弱对 SPARC、HP‑UX、32 位以及类似平台的支持。
- 有人认为“如果能编译，熟悉本地环境的专家通常就能让它跑起来”；也有人反驳说，“能编译”离“能工作”还差得很远。
- 这里存在一种张力：是聚焦主流的一线平台，还是保留小众系统的长尾生态。
谁应该适应谁？
- 一派观点：上游和用户应当自由采用 uv-build；Gentoo 可以打补丁、使用缓存，或放宽其政策。
- 另一派观点：如果可能，项目应默认使用简单/纯 Python 的后端，以避免把生态成本转嫁给源码型发行版。