这篇文章的标题是对 glyph 的 python packaging is good now 的引用。我认为可以肯定地说，在这8年里，我们已经从“好”变成了“伟大”。继续阅读我的推理。
是什么让 python 打包对于初学者来说变得困难？
我认为python打包的两个主要困难是
- 引导，即如何开始！
- 激活，即 python 中的 venvs 如何工作（参见我的 mastodon 线程，它很难解释！）
并且不要忘记整个虚拟环境生命周期。作为一个长期的 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 远远超出了这一点，它解决了其他开发者体验问题，对此我感到高兴和感激。
我正在有效地使用紫外线来完成所有事情，而且我不会回头。我会继续向大家推荐这个工具，继续谈论它，并希望它变得更广泛。
