这篇文章的标题是对 Glyph 的 Python Packaging is Good Now 的引用。我认为可以肯定地说，在这8年里，我们已经从“好”变成了“伟大”。继续阅读我的推理。

是什么让 Python 打包对于初学者来说变得困难？

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

• 引导，即如何开始！
• 激活，即 Python 中的 venvs 如何工作（参见我的 Mastodon 线程，它很难解释！）

引导是一个经常被忽视的问题。我们应该告诉人们从 https://python.org 安装 Python 吗？ Anaconda 分布？我们如何阻止人们使用他们的系统包管理器并冒破坏一切的风险？

并且不要忘记整个虚拟环境生命周期。作为一个长期的 Python 用户，我对它变得麻木了，这太疯狂了，但每次我必须解释它时，我看到我的学生的脸，我想“这不好”。

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

输入紫外线

2月15日，Astral发布了uv，我立即跳槽。作为我工作的一部分，我通常必须安装许多可能存在冲突的依赖项，而 uv 立即缓解了我的压力。

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

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

• uv 不依赖于 Python 本身。预编译的独立二进制文件可以轻松安装在 Linux、macOS 和 Windows 上。
• uv python 管理Python版本！无需求助于特定于操作系统的机制，如 pyenv、deadsnakes，或重量级工具，如 conda。
• uv 工具在集中式环境中管理工具！不再需要 pipx 或淡入淡出。
• uv init 使用孵化作为构建后端创建一个准系统 pyproject.toml 和一个带有空自述文件和虚拟模块的工作 src 布局。
  • 如果您需要更复杂的东西，您可以随时使用复印机或cookiecutter以及一些更复杂的模板。
• uv add 将依赖项添加到 pyproject.toml，如果不存在则创建一个 venv，并安装它们！
• uv lock 会创建一个包含所有依赖项的锁定文件，然后您可以在 uv 同步中使用该文件。
  • 如果您想要一个好的旧的requirements.txt，uv pip编译可以为您做到，就像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 生态系统也将不再在 virtualenv 激活中找到太多用处。

我还注意到 uv init 选择了孵化体。我一直对 PDM 有一点偏爱，但我认为这可能是一个不归路。

Leah 和贡献者花费了大量的精力才为 PyOpenSci 打包指南绘制了这个决策图。但事实上，现在有一个基线，人们可以在有更具体的需求时进行更改（例如，具有 Meson 或 scikit 构建能力的构建后端），这再次提供了更好的开发人员体验。

论康达

conda 与 pip 的主题是另一个常见的混乱来源。我从第一天起就是 conda 用户和粉丝，它有效地使 Python 免于死亡，当时在 Windows 上安装东西非常困难。

在接下来的几年里，我经常参考 Jake VanderPlas 解释这些差异的旧博客文章，但现在看来已经是失败的原因了。

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

我完全承认 conda 包更好地围绕非 Python 代码的概念构建，并且当前“PyPI 上的胖轮”的世界显然是一个次优的解决方案。但整个生态系统已经朝这个方向发展：大多数软件包现在都为各种平台发布了预编译的轮子。

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

结论

现在有点为时过早，因为其中一些 uv 命令仍处于实验阶段，并且可能在未来不断发展。但有史以来第一次，我清楚地看到一个工作流程工具，它符合标准、全面、无引导问题、经过精心设计，并且可以获胜。

这就是许多 Python 打包评论家一直想要的，对吗？不必从许多不同的工具中进行选择。但我认为 uv 远远超出了这一点，它解决了其他开发者体验问题，对此我感到高兴和感激。

我在所有事情上都有效地使用了紫外线，而且我不会回头。我会继续向大家推荐这个工具，继续谈论它，并希望它变得更广泛。