Python 打包现在很棒：`uv` 就是你所需要的一切

这篇文章的标题引用了 Glyph 的《Python 打包现在很好了》这篇文章。我想可以肯定地说，在这 8 年里，我们已经从“很好”迈向了“很棒”。请继续阅读，了解我的理由。

什么使得 Python 打包对于初学者来说很困难？

我认为 Python 打包的两个主要困难是

• 引导，即如何开始！
• 激活，即 Python 中的 venvs 如何工作。

引导是一个经常被忽视的问题。我们应该告诉人们从哪里安装 Python https://python.org？Anaconda 发行版？我们该如何阻止人们使用他们的系统包管理器，避免破坏所有东西的风险？

别忘了整个虚拟环境的生命周期。作为一个长期的 Python 用户，我对它已经麻木了，真是难以置信。但每次我不得不解释它的时候，看到学生们脸上的表情，我就会想：“这不行。”

当然，还有其他问题，比如如何构建和发布可分发的软件包。但我认为这些问题不会影响大多数 Python初学者。而且，这些问题也正在得到解决。请继续阅读。

进入uv

2月15日，Astral 发布了uv，我立刻就跳槽了。我的工作经常需要安装很多可能存在冲突的依赖包，现在uv终于可以松一口气了。

但有趣的是，它现在uv已经远远超出了最初的“更快的 pip”阶段，并且正在履行其成为“一个快速、可靠且易于使用的综合 Python 项目和包管理器”的承诺。

回到我一开始提到的引导和激活问题，如何uv解决它们？考虑一下：

• uv不依赖于 Python 本身。预编译的独立二进制文件可以轻松安装在 Linux、macOS 和 Windows 上。
• uv python管理 Python 版本！无需依赖特定于操作系统的机制（例如pyenv、deadsnakes），也无需使用重量级工具（例如conda）。
• uv tool在集中环境中管理工具！不再需要pipx或fades。
• uv initpyproject.toml使用hatchling构建后端和工作 src-layout 创建一个准系统，其中包含一个空的 README 和一个虚拟模块。
  • 如果您需要更复杂的东西，您可以随时使用copier或cookiecutter使用一些更复杂的模板。
• uv add添加依赖项pyproject.toml，如果不存在则创建一个venv，然后安装它们！
• uv lock创建一个包含所有依赖项的锁定文件，然后您可以在中使用该文件uv sync。
  • 如果您想要一个好的旧的requirements.txt，uv pip compile它适合您，就像pip-tools！
• uv run执行脚本和命令，同样无需明确激活环境！

本质上是这样的：

$ mkdir uv-playground
$ cd uv-playground
$ uv init
warning: `uv init` is experimental and may change without warning
Initialized project `uv-playground`
$ uv add click
warning: `uv add` is experimental and may change without warning
Using Python 3.12.3 interpreter at: /usr/bin/python3
Creating virtualenv at: .venv
Resolved 3 packages in 66ms
   Built uv-playground @ file:///tmp/uv-playground
Prepared 2 packages in 430ms
Installed 2 packages in 0.62ms
 + click==8.1.7
 + uv-playground==0.1.0 (from file:///tmp/uv-playground)
$ tree
.
├── pyproject.toml
├── README.md
├── src
│   └── uv_playground
│       ├── __init__.py
└── uv.lock

3 directories, 4 files
$ uv run python -c "from uv_playground import hello; print(hello())"
warning: `uv run` is experimental and may change without warning
Hello from uv-playground!

因此，对于“如何在计算机上开始学习 Python”这个问题，现在您可以普遍回答：“安装uv”。

一些思考

关于虚拟环境，我基本上同意 Armin 的说法

npm 没有任何与“激活”等效的功能，我认为未来的 Python 生态系统也将不再需要使用虚拟环境激活。

我还注意到uv init选择了hatchling。我一直对 PDM 略有偏好，但我认为这可能是一个不归路。

Leah 和贡献者们为 PyOpenSci 打包指南设计了这张决策图，耗费了大量心血。现在，有了一条基准线，方便大家根据更具体的需求（例如，需要 Meson 或支持 scikit-build 的构建后端）进行修改，这无疑为开发者带来了更佳的体验。

在 conda 上

conda 与 pip 的比较是另一个容易让人混淆的问题。我从第一天起就是 conda 的用户和粉丝，在 Windows 上安装东西非常困难的时代，它有效地拯救了 Python，使其免于消亡。

在随后的几年里，我经常参考Jake VanderPlas 的旧博客文章来解释这些差异，但现在看来已经无济于事了。

pip 和 conda 之间的互操作性问题从未得到完全解决，虽然我认为Pixi人员做得非常出色，但我认为从长远来看uv他们会获胜。

我完全承认，conda 软件包的结构更适合非 Python 代码，而目前“PyPI 上的 Fat Wheels”显然并非最佳解决方案。但整个生态系统已经朝着这个方向发展：现在大多数软件包都发布了针对各种平台的预编译 Wheels。

换句话说：conda 在 2024 年可能不再像 2014 年那么有用，也许是时候停止向初学者教授它并将其视为一种高级工具了。

结论

现在说这些还为时过早，因为其中一些命令仍处于实验阶段，未来可能会有所改进。但这是我第一次清晰地看到一个符合标准、功能全面、没有引导问题、设计精良、并且能够取得成功的uv工作流工具。

更新 2024-08-20：uv3.0 引入了project、、和接口，因此它们不再是实验性的tool！scriptpython

这正是许多 Python 打包批评者一直以来想要的，对吧？不用在众多不同的工具中做出选择。但我认为uv它远不止于此，还解决了其他开发者体验问题，对此我感到高兴和感激。

我uv在所有事情上都有效地使用它，而且我从未后悔过。我会继续向大家推荐这个工具，继续谈论它，并希望它能得到更广泛的传播。