前言

在 Python 開發(fā)中，虛擬環(huán)境和包管理工具是必不可少的。它們可以幫助我們更好地管理項目依賴，避免環(huán)境沖突，提高開發(fā)效率。但是依賴管理堪稱“頭號工程難題”——環(huán)境沖突、版本不一致、部署失敗等問題層出不窮。

由于Python的庫發(fā)展的非?？?，工具也是日新月異，搜索會發(fā)現有pip，venv、Virtualenv、Conda、Pipenv、Poetry、UV等等，你是否能把它們完全分清楚？
本文全面梳理解析截至目前的所有主流依賴工具，并分類介紹，涵蓋基礎工具、現代解決方案與新興神器，助你精準選擇最適合項目的武器庫！

在深入對比之前，我們先明確虛擬環(huán)境和包管理工具的核心作用：

• 包管理：管理項目的依賴包，包括安裝、更新、卸載等操作，并確保依賴關系的一致性。
• 虛擬環(huán)境：為每個項目創(chuàng)建一個獨立的Python運行環(huán)境，隔離依賴，避免不同項目之間的包版本沖突。

一、包管理工具

pip（Python官方，2008）

pip GitHub

定位：Python包安裝核心引擎，最基本也是最廣泛使用的 Python 包安裝工具，所有工具底層依賴 ，從PyPI安裝庫，由PyPA組織維護。

PyPA：指 Python Packaging Authority，一個維護 Python 打包相關項目的小組，包括 pip、packaging、setuptools、wheel、twine、build 等，相關項目具體見 https://github.com/pypa。

優(yōu)點：無需安裝，pip install 即用，支持PyPI源定制。

缺點：無依賴沖突解決能力，無環(huán)境隔離功能

場景：臨時腳本安裝包，其他工具的底層引擎

二、虛擬環(huán)境工具

1. virtualenv（Ian Bicking，2007）

virtualenv GitHub

舊時代的產物，除非還在使用python 2。

• 定位：第三方虛擬環(huán)境工具（支持Python 2/3）
• 功能：創(chuàng)建隔離環(huán)境，支持指定不同 Python 解釋器。依賴 pip 管理包。
• 優(yōu)點：支持舊版 Python（如 Python 2）。可指定任意Python解釋器，支持--system-site-packages復用系統包 。
• 缺點：需額外安裝，Windows兼容性較弱 。依賴管理需手動處理。無自動依賴解析。
• 場景：遺留Python 2項目維護，多解釋器版本測試。

# 安裝virtualenv   
pip install virtualenv      
# 創(chuàng)建虛擬環(huán)境   
virtualenv myenv      
# 激活虛擬環(huán)境   
# Windows   
myenv\Scripts\activate   
# macOS/Linux   
source myenv/bin/activate      
# 退出虛擬環(huán)境   
deactivate

2. venv（Python3.3，2012）

python自帶的虛擬環(huán)境管理，簡單是它的優(yōu)勢，也是它的劣勢。

只能創(chuàng)建虛擬環(huán)境，不能指定系統不存在的python環(huán)境版本，不能管理系統中的環(huán)境列表（例如選擇一個已經創(chuàng)建好了的虛擬環(huán)境）。

venv的虛擬環(huán)境默認是存放在項目文件夾里的，這會影響項目文件的管理。

• 定位：Python 3.3+內置的輕量級環(huán)境隔離
• 功能：創(chuàng)建隔離的 Python 環(huán)境，依賴 pip 手動管理包。
• 優(yōu)點：開箱即用，無額外依賴，目錄結構清晰。兼容性好，與"pip"無縫集成。
• 缺點：無依賴解析能力，需手動維護 requirements.txt。無法創(chuàng)建非系統Python版本環(huán)境 ，不支持多 Python 版本切換。
• 場景：快速驗證代碼或小型項目。如果你只需要基本的虛擬環(huán)境功能，"venv"是最輕量、最直接的選擇。

# 創(chuàng)建虛擬環(huán)境   
python -m venv myenv      
# 激活虛擬環(huán)境   
# Windows   
myenv\Scripts\activate   
# macOS/Linux   
source myenv/bin/activate      
# 退出虛擬環(huán)境   
deactivate

三、版本管理工具

pyenv（社區(qū)開發(fā)，2014）

pyenv GitHub

Pyenv 讓開發(fā)者可以在多個 Python 版本之間輕松切換，解決了 venv 不能創(chuàng)建不同 Python 版本虛擬環(huán)境的限制。

Pyenv 支持在不同項目中切換 Python 版本。

但是，開發(fā)者有時會濫用 pyenv 設置全局的 Python 版本，導致項目之間的 Python 版本混亂，影響項目的復用和開發(fā)環(huán)境的穩(wěn)定。

Pyenv 的理念很簡單，秉承了 UNIX 哲學中單一用途工具的傳統，它源自于 rbenv 和 ruby-build，并專門為 Python 進行了修改和適配。
與同類工具不同，pyenv 完全由純 Shell 腳本實現，不依賴 Python，無需擔心 Python 引導問題。

Pyenv 通過修改操作系統的 PATH 環(huán)境變量，可不同 Python 版本之間切換，并能同時運行多個 Python 版本的命令，在不同 Python 環(huán)境下進行測試和開發(fā)時特別實用。

pyenv 主要用于切換 Python 版本，并不直接管理虛擬環(huán)境。不過，可以結合 pyenv 與 virtualenv 命令，或使用 pyenv-virtualenv 插件管理虛擬環(huán)境。

• 定位：純Python版本管理工具（非依賴管理）。 主要用于管理多個 Python 版本，而不是直接管理包，但它可以用來設置特定版本的 Python 環(huán)境，進而使用其他包管理工具。
• 優(yōu)點：支持多版本無縫切換，解決“我本地是Python 3.10，服務器是3.8”的經典問題。
• 缺點：需配合venv/pipenv等使用，Windows支持較弱。
• 場景：需同時維護多個Python版本的項目。

四、項目管理工具：依賴+環(huán)境+打包三位一體

1. Pipenv（Kenneth Reitz，2017）

pipenv GitHub

requests庫作者Kenneth Reitz大神的作品。但pipenv并不穩(wěn)定，例如，如果你運行pip install…兩次，結果可能不一樣，pipenv曾承諾解決這個問題，但實際上，它只是多次嘗試運行pip install <單個包>，直到結果看起來差不多符合規(guī)范。顯然，這樣的方式更慢，但最終問題依然存在。

• 定位：首次整合pip+virtualenv的革命性工具，引入Pipfile和Pipfile.lock管理依賴。 Python 官方曾推薦的依賴管理工具。
• 功能：自動創(chuàng)建虛擬環(huán)境 + 依賴管理（Pipfile 和 Pipfile.lock）。解決依賴版本沖突。
• 優(yōu)點：自動管理虛擬環(huán)境，.env文件支持，統一開發(fā)和生產環(huán)境依賴。依賴哈希校驗提升安全性。 替代傳統 requirements.txt。
• 缺點：依賴解析速度慢，大型項目體驗不佳。 社區(qū)活躍度下降（逐漸被 Poetry 取代）。
• 場景：中小型Web應用，追求開箱即用的團隊。
• 動態(tài)：2025版移除Python 3.8支持，優(yōu)化依賴解析邏輯。

# 安裝pipenv   
pip install pipenv      
# 創(chuàng)建虛擬環(huán)境并安裝依賴   
pipenv install      
# 激活虛擬環(huán)境   
pipenv shell      
# 退出虛擬環(huán)境   
exit

2. Poetry（Sébastien Eustace，2018）

poetry GitHub

• 在uv出現前最好用的管理工具。
• poetry使用pyproject.toml和poetry.lock文件來管理依賴，類似于JavaScript/Node.js的Npm和Rust的Cargo，這倆都是非常成熟好用的依賴管理方案。
• poetry本身并不具有管理Python解釋器的功能，推薦和pyenv/pyenv-win使用，可以輕松下載和設置不同版本的Python解釋器。
• poetry的缺點可能是較為復雜，上手困難。由于poetry嚴格的依賴管理策略，你可能會在安裝依賴包時遇到更多的問題。
• 在國內，poetry還有另一個缺點，無法設置全局鏡像源，只可針對單個項目設置鏡像源。

Poetry 支持安裝和更新支持庫，提供鎖文件以確保項目的復用，并能構建項目分發(fā)包。

Poetry 需要 Python 3.8+，跨平臺支持 Linux、macOS 和 Windows。

Poetry 類似于 Cargo（Rust 的包管理器） 和 npm（Node.js 的包管理器），是 Python 生態(tài)系統中使用體驗與這兩個包最接近的工具。類似于 Conda，Poetry 預先解析完整的依賴圖，并按拓撲順序安裝支持庫。

Poetry 依據 pyproject.toml 管理項目內外的虛擬環(huán)境。

poetry.lock 文件可以確保項目的復用，但體積較大。此外，Poetry 還兼具構建工具功能，可以發(fā)布 Python 包。

Poetry 的解析速度較慢，部分是因為 Python 包聲明支持庫的方式不一致，可能會導致支持庫解析的時間較長。

• 定位：現代依賴管理 + 打包工具（開源庫開發(fā)首選）。全生命周期管理（依賴+打包+發(fā)布），基于pyproject.toml。
• 功能：一體化工具：集成了虛擬環(huán)境管理、依賴管理（pyproject.toml）和打包發(fā)布功能。
• 優(yōu)點：語義化版本控制，動態(tài)依賴約束（如 ^1.2.3）。一體化工具鏈（開發(fā)到發(fā)布全流程）。一鍵發(fā)布PyPI，依賴樹可視化。
• 缺點：冷啟動解析較慢，自定義構建流程支持弱。 學習成本較高（需熟悉 pyproject.toml）。對舊項目遷移有一定成本。
• 場景：復雜項目、開源庫開發(fā)、追求現代工作流。

# 安裝poetry   
pip install poetry      
# 創(chuàng)建新項目   
poetry new myproject      
# 添加依賴   
poetry add requests      
# 進入虛擬環(huán)境   
poetry shell

3. PDM（Frost Ming，2020）

pdm GitHub

PDM 的目標是成為新生代 Python 支持庫管理工具。

與 Poetry 類似，PDM 也是一款快速的支持庫解析器，主要用于大型二進制文件分發(fā)。

它具備靈活強大的插件系統和多功能用戶腳本。

此外，PDM 還可以使用 indygreg 的 python-build-standalone 安裝 Python，并支持類似 pnpm 的集中式安裝緩存。

PDM 與 Poetry 的主要區(qū)別在于，PDM 支持 PEP-582，將虛擬環(huán)境集成到項目目錄中，避免了傳統虛擬環(huán)境的手動激活和停用，提高了開發(fā)效率。

• 定位：PEP 582標準實踐者，支持項目本地包目錄，無需虛擬環(huán)境。
• 優(yōu)點：依賴解析快，避免環(huán)境激活，兼容pyproject.toml。
• 缺點：IDE支持需額外配置，非虛擬環(huán)境模式調試復雜。
• 場景：追求輕量化的微服務、工具鏈開發(fā)。

4. Rye（Astral，2023）

Rye GitHub

Rye 由 Astral.sh 開發(fā)，也是基于 Rust 構建的，旨在提升開發(fā)效率和用戶體驗。與傳統的包管理工具相比，Rye 的性能有顯著提升，功能也更加豐富。

Rye 希望為 Python 開發(fā)者提供一站式的工具，讓 Python 支持庫的安裝與管理更加輕松。

Rye 使用與 uv 相同的支持庫解析器，提供更快的管理體驗。

Rye 還提供了與 poetry 類似的功能，但速度更快。

定位：Poetry的極速替代品，共享uv解析引擎

5. uv（Astral，2024）

uv GitHub

uv 是一個由 Astral 開發(fā)的高性能 Python 包管理和項目管理工具，用 Rust 編寫，旨在取代傳統的 Python 工具（如 pip、virtualenv、poetry、甚至部分 pyenv 功能）。它以極快的速度和現代化的設計著稱，號稱比 pip 快 10-100 倍，比 Poetry 快 2-10 倍。uv 的目標是提供一個統一的、一站式的 Python 開發(fā)體驗，涵蓋包安裝、虛擬環(huán)境管理、項目管理和 Python 版本管理。

uv使用rust構建，uv的維護者astral還有另一個大名鼎鼎的python代碼格式化工具ruff，在使用ruff和uv時，你能明顯感覺到和其它基于python的工具的差距，指哪打哪，非常爽快。

uv和poetry一樣使用pyproject.toml和lock文件管理依賴，很現代，用過的都說好。

uv還同時管理python解釋器，也就是集成了pyenv的功能，可以方便地下載和管理解釋器。在python解釋器小版本更新時（例如3.12.0→3.12.1），uv也會自動更新，以后再也不用苦嘻嘻的去python官網找解釋器了。

將uv生成的項目拷貝到沒有python環(huán)境的電腦上，只需使用命令uv sync，uv會自動安裝python解釋器，并接著安裝pip依賴，如果使用uv run，uv還會在全部安裝妥當后，自動開始運行腳本。

uv甚至還集成了pipx安裝python全局工具的功能，例如ruff、isort、mypy、pyright這類全局工具，可以使用uv tool安裝、升級和管理。

即便你是一個純粹的“pip”命令愛好者，uv也可以滿足你。uv提供了uv pip系列命令，可以同時具備rust的爽快和pip的學院派感覺，堪稱古典與現代的結合。

在最新的pycharm版本（2024.3.2或以上）里也添加了uv的支持，使用pycharm和uv管理項目甚至不需要寫命令行。

uv 也是 Astral.sh 出品的 Python 虛擬環(huán)境管理器，是當前備受期待的新生代包管理工具。

uv 的目標是取代 pip，同時具備與 Cargo 類似的功能。

uv 支持 Python 打包工具的所有特性，包括可編輯安裝、Git 依賴、URL 依賴、本地依賴、約束文件和源碼分發(fā)等。

Astral.sh 還開發(fā)了 Rust 生態(tài)中備受開發(fā)者喜愛的 ruff （用 Rust 開發(fā)的高性能 Python 代碼檢查和代碼格式化工具）。與 poetry 類似，uv 通過 pyproject.toml 管理項目，得益于 Rust 的高效算法，其解析速度至少比 poetry 快一個量級。

定位：新一代高性能 Python 工具，Rust編寫的超高速一體化工具

功能：超高速包安裝與依賴解析（兼容 pip 和 pip-tools 工作流）。支持虛擬環(huán)境管理（類似 venv）。支持生成 requirements.txt 和 pyproject.toml。

性能對比（Jupyter項目）：

命令全景：

uv pip install numpy          # 替代pip
uv venv .env                  # 替代virtualenv
uv python install 3.12        # 替代pyenv
uv run main.py                # 替代poetry run

定位：Rust編寫的超高速一體化工具，覆蓋pyenv+venv+pip+poetry功能。

優(yōu)點：

• 速度：依賴解析比pip快100倍（Jupyter項目冷啟動500ms → 熱緩存20ms）
• 全能：支持Python版本管理（uv python install）、依賴鎖定（uv lock）、腳本執(zhí)行（uv run）
• 安全：跨平臺鎖文件，哈希校驗防篡改
• 跨平臺：支持Windows、macOS和Linux。

缺點：生態(tài)適配中，暫不支持非Python依賴（如Conda的C++庫）。

場景：所有純Python項目的首選替代方案，尤其適合CI/CD流水線。

# 安裝uv   
pip install uv      
# 創(chuàng)建虛擬環(huán)境   
uv venv myenv      
# 激活虛擬環(huán)境   
# Windows   
myenv\Scripts\activate   
# macOS/Linux   
source myenv/bin/activate      
# 退出虛擬環(huán)境   
deactivate

五、科學計算：非Python依賴管理

1. Conda（Anaconda團隊，2012）

conda GitHub

conda 和 Anaconda 是兩回事：

• conda 是包管理器（開源，BSD 許可證，仍然免費）。
• Anaconda 是一個商業(yè)公司提供的 Python 發(fā)行版，包括 conda、本地鏡像源、大量預裝包等。

從 2020 年起，Anaconda 公司對商業(yè)用途（如公司或機構）使用其官方發(fā)行版和鏡像源實行了收費政策：

• 個人用戶、開源項目、學術研究用途仍然免費。
• 企業(yè)用戶如果通過 Anaconda 鏡像或工具部署，需要購買許可證。

anaconda實在過于臃腫，它的安裝包里包括了眾多科學計算會用到的packages，安裝后動輒5-6個G。

anaconda有個不包含packages的版本，叫miniconda，但miniconda仍然存在安裝依賴庫過于激進的問題，安裝同樣的packages，conda總會比別的包管理器安裝更多的“依賴包”，即便有的“依賴包”并不是必須，這會導致你的項目出現不必要的膨脹。

同時，conda的packages列表“conda list”還存在和“pip list”不一致的問題。

Conda 是由 Anaconda 出品的命令行工具，用于在 Windows、macOS 和 Linux 上管理虛擬環(huán)境。它不僅能管理 Python 支持庫，還能處理非 Python 支持庫，尤其針對數據科學方面的開發(fā)進行了優(yōu)化。

Conda 使用自己的 Conda 虛擬環(huán)境切換非 Python 依賴項，無需使用復雜的 Docker。與 Poetry 類似，Conda 在構建環(huán)境時執(zhí)行完整的支持庫解析，其支持庫解析器 libmamba 是用 C++ 實現的，速度更快。

• 定位：跨語言包與環(huán)境管理（科學計算領域主流）。 （Python/R/CUDA）
• 功能：管理 Python 和非 Python 依賴（如 C/C++、R 庫）。自帶預編譯包（優(yōu)化科學計算庫安裝）。
• 優(yōu)點：跨平臺：支持Windows、macOS和Linux。一鍵安裝SciPy棧，支持Python/R/CUDA等混合依賴，預編譯加速科學庫安裝。
• 缺點：包更新滯后PyPI，虛擬環(huán)境切換慢。 環(huán)境體積臃腫（Miniconda>1GB） 。復雜依賴解析可能沖突。
• 場景：數據科學、機器學習、跨學科項目。

# 創(chuàng)建虛擬環(huán)境   
conda create -n myenv python=3.8      
# 激活虛擬環(huán)境   
conda activate myenv      
# 退出虛擬環(huán)境   
conda deactivate

2. Mamba（2019年）

mamba GitHub

是Conda的改進版，旨在解決Conda的痛點，如慢的依賴解析和并行下載問題，用 C++ 實現，使用不同算法，推薦安裝方式已改變。
速度比Conda 快很多，其他方面和Conda類似。

3. Miniforge（conda-forge社區(qū)，2020）

miniforge GitHub

• 定位：Conda輕量替代版，默認conda-forge源
• 場景：數據科學輕量化部署

4. Pixi（Prefix.dev團隊，2024）

pixi GitHub

Pixi 是基于 Rust 的 rattler 庫開發(fā)的，具有顯著的性能和安全優(yōu)勢。它的理念是提供類似于 cargo 或 yarn 的開發(fā)體驗。

Pixi 目標是直接取代 Conda，并能像 Conda 一樣管理非 Python 依賴項。

2024 年 2 月，為了追求更快的速度，Pixi 將后臺的 rip 改為 uv。與 Conda 和 mamba 不同，Pixi 提供了自定義類型的鎖文件，使其在復用方面領先于 Conda。

Pixi 支持可復用的方式安裝支持庫，并支持 Python、C++ 和 R 等多種語言， 且兼容所有主流操作系統。

Pixi 還提供了簡潔而強大的命令行界面，使得支持庫管理更加簡單、高效。

• 定位：Conda的現代替代品，基于Rust構建。 ，支持pyproject.toml
• 優(yōu)點：兼容Conda庫且解析更快，支持pyproject.toml。 混合管理PyPI和Conda包，解析速度提升5倍
• 缺點：社區(qū)包覆蓋不全。
• 場景：需混合PyPI和Conda包的跨語言工程。

六、依賴管理工具：專治版本混亂

1. pip-tools（Vincent Driessen團隊，2013）

pip-tools GitHub

定位：生產級精準依賴鎖定

核心命令：

• pip-compile：從.in文件生成帶哈希的requirements.txt
• pip-sync：嚴格同步環(huán)境至鎖定狀態(tài)

場景：Docker鏡像構建，生產服務器部署

2. pipreqs（社區(qū)，2016）

pipreqs GitHub

• 定位：基于項目import語句生成純凈requirements.txt。
• 神技：pipreqs /project --ignore node_modules --encoding=utf8
• 優(yōu)點：自動忽略虛擬環(huán)境目錄，支持--ignore排除無關路徑。
• 缺點：無法識別動態(tài)導入（如__import__('os')）。
• 場景：從遺留項目重構依賴，生成最小化生產環(huán)境清單。

3. pigar（社區(qū)，2018）

pigar GitHub

• 定位：AST解析依賴，標注依賴在代碼中的位置。
• 優(yōu)點：精確識別跨版本標準庫（如Py2的futures vs Py3的concurrent.futures）。
• 缺點：輸出文件含位置注釋，需手動清理后部署。
• 場景：審計依賴來源，解決“這個包到底在哪用？”的靈魂拷問。

# 輸出帶代碼位置注釋的requirements.txt
$ pigar -p /project -o requirements.txt

4. pipdeptree（社區(qū)，2015）

pipdeptree GitHub

• 定位：可視化依賴樹與沖突檢測。
• 優(yōu)點：提示循環(huán)依賴，生成沖突報告（如pkgA需要numpy<2.0，pkgB需要numpy>=2.0）。
• 缺點：需在每個虛擬環(huán)境中單獨安裝。
• 場景：診斷依賴沖突，架構治理。

# 檢測沖突示例
$ pipdeptree --warn conflict | grep "version conflict"

七、終極對比表：13款工具全景圖

八、依賴管理工具時間簡史

2000年，setuptools

Python2自2000年發(fā)布以來，語言尚未完全穩(wěn)定和成型，最開始通過easy_install（2004 年發(fā)布，屬于 setuptools 的一部分）從PyPI（2003 年上線）安裝.egg格式的包。

2008年，pip+virtualenv

2008年，為了解決Python2中的一些設計缺陷和向后不兼容的問題，發(fā)布Python 3.0。隨著社區(qū)的建設，PyPI的庫越來越多，python官方發(fā)布了包管理工具pip用于從PyPI安裝庫，同樣的，python的版本也在增多，不同版本之間庫版本兼容不同，pip本身只是給全局環(huán)境直接安裝一套一樣的依賴，如果有兩個項目依賴于同一個庫的不同版本，你是不可能同時在全局環(huán)境里把這兩個版本都裝上的。為了避免沖突，最好是給每個項目都有一套獨立的 pip 環(huán)境，分別安裝各自需要的依賴，這個就是虛擬環(huán)境，第三方庫率先發(fā)布了virtualenv實現環(huán)境管理。

2012年，venv

此時，包管理和環(huán)境管理工具為pip+virtualenv。2012年，Python3.3發(fā)布，內置了環(huán)境管理工具venv，內置的更高效和方便，就替代了virtualenv。你用 PyCharm 創(chuàng)建項目時，默認會用 venv 建一個虛擬環(huán)境，也就是你看到的 venv 文件夾，就是為了讓每個項目都有獨立的依賴，避免沖突。

2013年，pip-tools

venv 在簡單的場景下大概足夠了，你也可以直接進入虛擬環(huán)境導出 requirements.txt 或手寫個 pyproject.toml 來聲明依賴。但是你可能不太喜歡這種完全“手動擋”的模式，而是希望有一些更加方便的工具，可以讓你直接輸入一個 xxx-tool install 命令就直接檢測項目目錄下的 requirements.txt 或 pyproject.toml，利用里邊寫明的依賴自動生成一個虛擬環(huán)境，如果已經有虛擬環(huán)境就安裝缺少的庫/移除不再需要的庫，然后使用 xxx-tool add lib1 這種命令就能自動更新 requirements.txt 或 pyproject.toml并自動在虛擬環(huán)境中安裝 lib1。

于是2013年，社區(qū)發(fā)布了pip-tools，它提供兩個命令：pip-compile 用于生成和操作依賴清單（requirements.txt，注意這個 requirements.txt 和 Python 舊標準中的同名文件所功能不一樣，在 pip-tools 中它更類似于一個 lockfile），pip-sync 用于根據依賴清單將其內容與當前虛擬環(huán)境同步。但是 pip-tools 本身不會做更多事情了，它只聚焦于提供這兩個命令——如果你需要添加/刪除一個包或將某個包更新到與原本不兼容的版本，你需要先操作 pyproject.toml、使用 pip-compile 重新生成 requirements.txt，然后再用 pip-sync 同步進去。pip-tools 本身也只是同步當前的 pip 環(huán)境，不關心虛擬環(huán)境的事情，如果你要與 venv 一起使用，得先激活 venv 在里邊操作 pip-tools 才行。

2014年，pyenv

隨著python版本的更新，越來越多的開發(fā)者需要同時在不同的python版本下工作，手動切換總是很麻煩。社區(qū)在2014年發(fā)布了pyenv，pyenv 是一個純Python版本管理工具（非依賴管理），pyenv 完全由純 Shell 腳本實現，不依賴 Python。 主要用于管理多個 Python 版本，而不是直接管理包，但它可以用來設置特定版本的 Python 環(huán)境，進而使用其他包管理工具。

2017年，pipenv

目前開發(fā)工具集就是pip+venv+pip-tools+pyenv，雖然解決了需求，但是實際操作起來還是很麻煩。更復雜的是當你試圖編寫一個庫并發(fā)布到 PyPI 的時候——此時你需要一個構建工具、一個打包工具和一個負責把包發(fā)布到 PyPI 的工具。如果你需要一套標準流程，全部利用 Python 文檔中推薦的東西大概需要結合 setuptools + python -m build + Twine（分別負責構建、打包和發(fā)布到 PyPI）。

此時迫切的需要一個新的工具把這一連串的流程全打通，2017年，requests庫的作者Kenneth Reitz大神出品了pipenv，首次整合pip+virtualenv的革命性工具，引入Pipfile和Pipfile.lock管理依賴。 Python 官方曾推薦的依賴管理工具。

2018年，poetry

但pipenv并不穩(wěn)定，2018年，社區(qū)發(fā)布了poetry，這是最早可用的現代化項目管理工具，基于pyproject.toml，進行全生命周期管理（依賴+打包+發(fā)布），是開源庫開發(fā)的首選。

2020年，PDM

Poetry 的問題首先在于它并不完全符合標準，典型的如它默認的 pyproject.toml 格式不符合 PEP 621（盡管目前已有實驗性支持）——因為 Poetry 的出現比 PEP 621 更早，自然不能未卜先知。另一個問題在于 Poetry 在解析依賴上的性能不盡如人意，一個 poetry add 常常需要花幾十秒時間，這顯然不夠理想。
所以自然出現了“更符合標準”的工具，2020年，社區(qū)推出了PEP 582標準實踐者PDM。

2023年，Rye

這些工具各有各的特點，也各有各的問題。首先是這些工具作為針對單個項目的依賴管理工具與構建工具，本身并不管理 Python 本身——許多用戶是有客觀的同時使用多個版本 Python 的需求的，有些人會用 pyenv 編譯安裝多個版本的 Python，有些人直接用包管理器切換 shims，有些人則直接使用 Conda——這個需求顯然是這些項目管理工具做不到的；其次是工具安裝的問題，有時我們會需要用 pip 安裝一些命令行工具，比如 black 和 ruff，但直接使用 pip 安裝到全局環(huán)境中很容易產生依賴沖突，也會污染全局依賴，所以有了 pipx 這樣的項目用于為每個工具創(chuàng)建單獨的隔離虛擬環(huán)境。

所以我們看到至少還有兩個需求，即 pyenv 與 pipx 的任務可以進一步整合進來。2023年，Astral.sh大神發(fā)布了基于Rust的Rye，它不僅整合了 Poetry 的功能，也可以像 pyenv 或 Conda 一樣在你的機器上管理多個 Python 版本、像 pipx 一樣以隔離環(huán)境安裝工具，也整合了 ruff 作為開箱即用的 Linter 和 Formatter，對 pytest 也提供了支持。Rye 實際上不像 Poetry/Hatch/PDM 一樣實現了自己的依賴解析系統和構建后端，而只是將各種工具（uv/pip-tools、Hatchling、build、Twine 等）整合到一起，讓它們能夠協同工作，更近似一個“前端”項目。

2024年，uv

由于pip的速度較慢，Astral.sh于2024年2月發(fā)布了uv，一開始只是一個更快的包安裝工具和依賴解析工具，用 Rust 編寫，旨在作為 pip 和 pip-tools 性能更好的替代品。在發(fā)布之后Rye于同月把包管理由pip替換為了uv。

后來，rye的初始作者最近把項目移交給uv團隊了, 相當于兩個項目合并。在 0.3.0 (2024/08) 加入了 python 環(huán)境管理和項目管理。到現在，已經完全可以用uv替代Rye了。

至此，python的依賴管理工具終于迎來了短暫的終局，以后隨著python的發(fā)展和社區(qū)的發(fā)展，可能會繼續(xù)出現新的劃時代的工具

科學計算

科學計算環(huán)境下，由于需要用到各種語言的庫，是一個單獨的領域，就統一說一下。

• 2012年，Conda/miniconda，跨語言包與環(huán)境管理（Python/R/CUDA）
• 2020年，Anaconda 收費后，conda-forge社區(qū)發(fā)布了Miniforge
• 2019年，Mamba，作為Conda的輕量級替代品
• 2024年，pixi，Conda的現代替代品，基于Rust構建。

九、2025年工具選型黃金法則

初學者或簡單項目：先拿pip+venv練手，掌握基本原理

庫開發(fā)者：堅持 Poetry（生態(tài)最成熟，PyPI發(fā)布無縫銜接）

數據科學： 傳統是Conda，非Python依賴（如CUDA、MKL）必須靠它。 如果同時使用PyPI庫和團隊協作就用Pixi

Python2舊項目：Virtualenv管理環(huán)境，uv管理庫，

重構舊項目：用pipreqs+pipdeptree，先精準分析依賴，再解決沖突

其他：一律推薦uv，無論腳本還是工程，Rust工具鏈的速度與體驗碾壓傳統方案。

十、未來趨勢預測

Rust工具鏈統治：uv安裝量已占PyPI流量25%（2025數據），Rye/Pixi等Rust工具將逐步取代Python實現工具。

標準趨同：pyproject.toml成為依賴聲明事實標準（Poetry/PDM/UV/Rye/Pixi均已支持）。

AI輔助依賴協商：GPT-DependencySolver等工具將自動解決版本沖突（實驗階段）。

容器化融合：uv run已支持直接啟動隔離容器環(huán)境，未來工具鏈將深度整合Docker。

以上就是Python中依賴管理工具使用終極指南(保姆級教程)的詳細內容，更多關于Python依賴管理的資料請關注腳本之家其它相關文章！

最新評論