Uv 很棒，但它的包管理 UX 很混乱

uv 非常棒，但它的包管理用户体验却一团糟 2026 年 5 月 21 日 • #python 和 #uv Astral 的 uv 席卷了 Python 世界，这是有充分理由的。它速度极快，可以轻松处理 Python 版本，并用一个二进制文件取代了六个工具。我之前写过多篇关于它的文章。使用 uv 开始一个新的 Python 项目并添加第一个依赖项非常简单。但是，一旦您完成了项目的初始设置并进入了维护阶段，即检查过时的软件包并执行例行升级，与 pnpm 或 Poetry 等同类产品相比，CLI 就开始显得异常笨重。查找过时的包 在我的 JavaScript 项目中，如果我想查看哪些内容需要更新，我会运行： $ pnpm outdated 这会提供一个干净、简洁的过时包列表、它们的当前版本、最新版本以及您的约束所允许的版本。在uv中，没有uv过时。相反，你必须记住下面这句： $ uv tree --outdated --depth 1 输出也是一个问题。它不仅向您展示什么是过时的，而且还向您展示什么是过时的。它向您显示整个顶级依赖关系树，并在有可用更新的依赖关系树旁边有一个小注释。如果您有 50 个依赖项，并且只有两个过时，您仍然需要扫描 50 行列表。 Poetry 的命令 Poetry show --outdated 并没有好多少，但至少它只显示实际过时的包。默认情况下不安全的版本约束 这是 uv 与 pnpm 和 Poetry 的最重要的哲学背离，对于生产稳定性来说这是一个危险的背离。 pnpm/Poetry 如何处理它当您使用 pnpm add 添加包时，它会使用插入符要求 ( ^1.23.4 ) 将其写入 package.json 。开头的插入符号表示允许任何 1.x.x 版本，但不会更新到 2.0.0。默认情况下，Poetry 会执行相同的操作，使用类似 >=1.23.4,<2.0.0 的格式。我发现这比 ^1.23.4 可读性较差，但效果是相同的。在这两种情况下，默认情况下更新都是安全的。您可以每天早上运行 pnpm update 或诗歌更新，并且非常有信心您的构建不会由于重大 API 更改而中断（假设您依赖的包尊重 SemVer）。 uv 如何处理它 当您运行 uv add pydantic 时，它会将其插入到您的 pyproject.toml 中： dependency = [ "pydantic>=2.13.4" , ] 请注意缺少上限。在uv看来，pydantic版本2、3、100都是完全可以接受的。这意味着 uv 更新默认是不安全的。如果您运行批量更新，您不仅会得到错误修复，还会得到修复。您选择接受依赖关系图中每个维护者发布的每个重大更改。升级命令糟糕的用户体验 在 uv 中实际执行更新的命令感觉像是为机器而不是人类设计的。如果您想更新 pnpm 或 Poetry 中的所有内容，只需一个简单的 pnpm update 或 Poetry update 命令。在 uv 中，你使用： $ uv lock --upgrade 由于上面提到的“无上限”问题，uv lock --upgrade 是一个核选项。它会将锁定文件中的每个软件包升级到绝对最新版本，忽略 SemVer 安全性。这包括您从未听说过的深层嵌套依赖关系！祝你好运，最好希望没有任何地方发生重大变化。一旦您意识到这风险太大，您就会只想升级特定的软件包。在搜索 uv tree --outdated --depth 1 的低于标准输出以找到它们之后，语法变成了重复的苦差事。 pnpm 是如何做到的： $ pnpm update pydantic httpx uvicorn uv 是如何做到的： $ uv lock --upgrade-package pydantic --upgrade-package httpx --upgrade-package uvicorn 当您想要更新一堆软件包时，必须为每个项目重复 --upgrade-package 标志是一个巨大的麻烦。我不明白为什么 uv 命令的用户体验这么差。希望是存在的：bounds 标志幸运的是 uv 最近为 uv add 引入了一个 --bounds 选项： $ uv add pydantic --bounds Major 这会产生我们所期望的更安全的 pydantic>=2.13.4,<3.0.0 约束。不过，目前这是一项可选择加入的功能。你必须记住每次都输入它，到目前为止，它被认为是预览功能。在 --bounds Major （或类似的配置）成为默认行为之前，uv 用户本质上被迫在两个糟糕的选项之间进行选择：手动编辑 pyproject.toml 为每个依赖项添加上限。担心 uv lock --upgrade 会意外地引入重大版本更改。我想看到的我喜欢紫外线。它的速度是革命性的，它管理 Python 工具链的方式是首屈一指的。但作为包管理器，开发人员维护项目的体验目前比之前的工具倒退了一步。我们需要一个专门的 uv 过时命令来过滤噪音，一个更符合人体工程学的更新命令，不需要重复标志，以及尊重语义版本控制健全性的默认版本约束。直到t