Uv：用 Rust 实现的 Python 打包工具
一个新的基于 Rust 的 Python 包管理器 uv，目标是成为 pip 和 pip-tools 的即插即用、快得多的替代品，并进一步成长为类似“Python 版 Cargo”的单二进制工具，同时管理虚拟环境和解释器。评论者认为，它的速度和对标准的良好兼容性，相比当今碎片化的 Python 打包生态是显著的体验提升；但也围绕平台无关 lockfile、可编辑工作流，以及对原生二进制的稳健处理等缺失功能展开争论。除了源自 Ruff 成功经验的热情之外，人们也明显担忧其长期可持续性、Python Software Foundation 在选择“唯一正确方式”中的角色，以及一家 VC 支持的公司成为生态系统关键基础设施的风险。
总体情绪
- 许多人表示兴奋，引用了对 Ruff 的良好体验，并期待一个快速的、基于 Rust 的“pip 替代品”。
- 也有人持怀疑态度，认为 uv 只是“又一个 Python 包管理器”，除非它成为事实标准，否则可能会加剧碎片化。
Python 打包的复杂性与对标准的渴望
- 多条评论抱怨这个生态系统令人困惑：venv、pip、pipx、Poetry、Conda 等，尤其对初学者而言更是如此。
- 很多人希望 python.org 能认可一种官方、带立场的工作流；也对核心治理层回避“选定赢家”感到沮丧。
uv 与现有工具（pip、pip-tools、Poetry、Conda、Pixi、Hatch、Rye）
- uv 被描述为可兼容 pip/pip-tools 工作流，并与 Rye 集成；有些人觉得 Rye→uv 的过渡很奇怪，但在听过解释后可以接受。
- 与 Pixi、Hatch 以及 Conda/mamba 的比较也很多：有人希望这些努力能统一起来；也有人提到 conda 在处理复杂原生依赖方面的优势。
- 也有人试用 uv 后发现不兼容之处（例如缺少
--upgrade、list -o），因此质疑其“即插即用替代品”的说法。
特性、设计选择与限制
- 受到称赞的点包括：快速的依赖解析、最低版本解析模式、可针对任意 Python 版本、对本地目录的可编辑安装、Git/URL 安装（但不支持可编辑 Git URL）。
- 当前限制：没有平台无关的 lockfile；维护者表示这是 v1 阶段的有意选择，并且已在路线图中。
- 对预发布版本的处理较保守：只有一方依赖带明确标记或全局开关时才会启用；尚不支持传递性预发布版本。
性能
- 多个经验性基准显示：uv 在冷安装时通常比 pip 快 2–4 倍，而在热缓存下则快得多。
- 用户将其与 npm→Yarn/Bun 的速度跃升相比较，并视为显著提升使用体验的改进。
生产环境、工作流与环境管理
- 关于“开发 vs 生产”的问题：一些人预计会采用多阶段构建，其中 uv 只存在于构建阶段。
- 大家非常希望 Python 版本安装能像 rustup 一样无缝；据说这也在路线图上。
Lockfile 与跨平台问题
- 围绕平台特定 vs 平台无关 lockfile 展开讨论。一些人认为不可移植的文件是致命缺陷；另一些人则提到 PyTorch 和新 Python 版本等边缘情况。
- 类似 Poetry/PDM 的 lockfile——能枚举所有平台上的所有 wheel 及传递性依赖——被视为理想目标。
安全性与正确性
- 一位评论者指出，当前对供应链安全的关注并不明显，并提到安装时执行代码的风险；其他人则链接到 pip 中此前出现过的类似案例。
治理、资金与生态风险
- 有人担心一家由 VC 支持的公司会成为生态系统的关键依赖；这与 npm 的类比，以及对“拥抱、扩展、消灭”的担忧相呼应。
- 缓解性的观点包括：宽松许可证允许分叉；也有人认为更快、更好的工具本身就已经带来巨大的净收益。
- 更广泛的批评是，Python 的领导层对打包基础设施投入不足，把太多工作留给资源匮乏的志愿者。
Rust vs Python 实现
- Rust 被认为是速度和以单一二进制分发的关键，也有助于引导 Python 本身的启动。
- 也有人认为依赖 Rust 会把 Python 社区的一部分人排除在贡献之外；另一些人则指出，大多数用户其实并不会去修改工具链。