Python 封装现在很棒：“uv”就是您所需要的

这篇文章的标题是对 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 布局。

• 如果您需要更复杂的东西，您可以随时使用复印机或饼干切割机以及一些更复杂的模板。

uv add 将依赖项添加到 pyproject.toml，

• 创建一个 venv（如果不存在），并安装它们！
  

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
│       └── __pycache__
│           └── __init__.cpython-312.pyc
└── uv.lock

4 directories, 5 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 上的胖轮子”的世界显然是一个次优的解决方案。但整个生态系统已经朝这个方向发展：大多数软件包现在都为各种平台发布了预编译的轮子。

立即学习“Python免费学习笔记（深入）”；

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

结论

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

获胜

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

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