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 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 遠遠超出了這一點，它解決了其他開發者體驗問題，對此我感到高興和感激。

我正在有效地使用紫外線來完成所有事情，而且我不會回頭。我會繼續向大家推薦這個工具，繼續談論它，並希望它變得更廣泛。

以上是Python 封裝現在很棒：「uv」就是您所需要的的詳細內容。更多資訊請關注PHP中文網其他相關文章！