Python中依赖管理工具使用终极指南(保姆级教程)

前言

在 Python 开发中，虚拟环境和包管理工具是必不可少的。它们可以帮助我们更好地管理项目依赖，避免环境冲突，提高开发效率。但是依赖管理堪称“头号工程难题”——环境冲突、版本不一致、部署失败等问题层出不穷。

由于Python的库发展的非常快，工具也是日新月异，搜索会发现有pip，venv、Virtualenv、Conda、Pipenv、Poetry、UV等等，你是否能把它们完全分清楚？
本文全面梳理解析截至目前的所有主流依赖工具，并分类介绍，涵盖基础工具、现代解决方案与新兴神器，助你精准选择最适合项目的武器库！

在深入对比之前，我们先明确虚拟环境和包管理工具的核心作用：

• 包管理：管理项目的依赖包，包括安装、更新、卸载等操作，并确保依赖关系的一致性。
• 虚拟环境：为每个项目创建一个独立的Python运行环境，隔离依赖，避免不同项目之间的包版本冲突。

一、包管理工具

pip（Python官方，2008）

pip GitHub

定位：Python包安装核心引擎，最基本也是最广泛使用的 Python 包安装工具，所有工具底层依赖 ，从PyPI安装库，由PyPA组织维护。

PyPA：指 Python Packaging Authority，一个维护 Python 打包相关项目的小组，包括 pip、packaging、setuptools、wheel、twine、build 等，相关项目具体见 https://github.com/pypa。

优点：无需安装，pip install 即用，支持PyPI源定制。

缺点：无依赖冲突解决能力，无环境隔离功能

场景：临时脚本安装包，其他工具的底层引擎

二、虚拟环境工具

1. virtualenv（Ian Bicking，2007）

virtualenv GitHub

旧时代的产物，除非还在使用python 2。

• 定位：第三方虚拟环境工具（支持Python 2/3）
• 功能：创建隔离环境，支持指定不同 Python 解释器。依赖 pip 管理包。
• 优点：支持旧版 Python（如 Python 2）。可指定任意Python解释器，支持--system-site-packages复用系统包 。
• 缺点：需额外安装，Windows兼容性较弱 。依赖管理需手动处理。无自动依赖解析。
• 场景：遗留Python 2项目维护，多解释器版本测试。

# 安装virtualenv   
pip install virtualenv      
# 创建虚拟环境   
virtualenv myenv      
# 激活虚拟环境   
# Windows   
myenv\Scripts\activate   
# macOS/Linux   
source myenv/bin/activate      
# 退出虚拟环境   
deactivate

2. venv（Python3.3，2012）

python自带的虚拟环境管理，简单是它的优势，也是它的劣势。

只能创建虚拟环境，不能指定系统不存在的python环境版本，不能管理系统中的环境列表（例如选择一个已经创建好了的虚拟环境）。

venv的虚拟环境默认是存放在项目文件夹里的，这会影响项目文件的管理。

• 定位：Python 3.3+内置的轻量级环境隔离
• 功能：创建隔离的 Python 环境，依赖 pip 手动管理包。
• 优点：开箱即用，无额外依赖，目录结构清晰。兼容性好，与"pip"无缝集成。
• 缺点：无依赖解析能力，需手动维护 requirements.txt。无法创建非系统Python版本环境 ，不支持多 Python 版本切换。
• 场景：快速验证代码或小型项目。如果你只需要基本的虚拟环境功能，"venv"是最轻量、最直接的选择。

# 创建虚拟环境   
python -m venv myenv      
# 激活虚拟环境   
# Windows   
myenv\Scripts\activate   
# macOS/Linux   
source myenv/bin/activate      
# 退出虚拟环境   
deactivate

三、版本管理工具

pyenv（社区开发，2014）

pyenv GitHub

Pyenv 让开发者可以在多个 Python 版本之间轻松切换，解决了 venv 不能创建不同 Python 版本虚拟环境的限制。

Pyenv 支持在不同项目中切换 Python 版本。

但是，开发者有时会滥用 pyenv 设置全局的 Python 版本，导致项目之间的 Python 版本混乱，影响项目的复用和开发环境的稳定。

Pyenv 的理念很简单，秉承了 UNIX 哲学中单一用途工具的传统，它源自于 rbenv 和 ruby-build，并专门为 Python 进行了修改和适配。
与同类工具不同，pyenv 完全由纯 Shell 脚本实现，不依赖 Python，无需担心 Python 引导问题。

Pyenv 通过修改操作系统的 PATH 环境变量，可不同 Python 版本之间切换，并能同时运行多个 Python 版本的命令，在不同 Python 环境下进行测试和开发时特别实用。

pyenv 主要用于切换 Python 版本，并不直接管理虚拟环境。不过，可以结合 pyenv 与 virtualenv 命令，或使用 pyenv-virtualenv 插件管理虚拟环境。

• 定位：纯Python版本管理工具（非依赖管理）。 主要用于管理多个 Python 版本，而不是直接管理包，但它可以用来设置特定版本的 Python 环境，进而使用其他包管理工具。
• 优点：支持多版本无缝切换，解决“我本地是Python 3.10，服务器是3.8”的经典问题。
• 缺点：需配合venv/pipenv等使用，Windows支持较弱。
• 场景：需同时维护多个Python版本的项目。

四、项目管理工具：依赖+环境+打包三位一体

1. Pipenv（Kenneth Reitz，2017）

pipenv GitHub

requests库作者Kenneth Reitz大神的作品。但pipenv并不稳定，例如，如果你运行pip install…两次，结果可能不一样，pipenv曾承诺解决这个问题，但实际上，它只是多次尝试运行pip install <单个包>，直到结果看起来差不多符合规范。显然，这样的方式更慢，但最终问题依然存在。

• 定位：首次整合pip+virtualenv的革命性工具，引入Pipfile和Pipfile.lock管理依赖。 Python 官方曾推荐的依赖管理工具。
• 功能：自动创建虚拟环境 + 依赖管理（Pipfile 和 Pipfile.lock）。解决依赖版本冲突。
• 优点：自动管理虚拟环境，.env文件支持，统一开发和生产环境依赖。依赖哈希校验提升安全性。 替代传统 requirements.txt。
• 缺点：依赖解析速度慢，大型项目体验不佳。 社区活跃度下降（逐渐被 Poetry 取代）。
• 场景：中小型Web应用，追求开箱即用的团队。
• 动态：2025版移除Python 3.8支持，优化依赖解析逻辑。

# 安装pipenv   
pip install pipenv      
# 创建虚拟环境并安装依赖   
pipenv install      
# 激活虚拟环境   
pipenv shell      
# 退出虚拟环境   
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 支持安装和更新支持库，提供锁文件以确保项目的复用，并能构建项目分发包。

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

Poetry 类似于 Cargo（Rust 的包管理器） 和 npm（Node.js 的包管理器），是 Python 生态系统中使用体验与这两个包最接近的工具。类似于 Conda，Poetry 预先解析完整的依赖图，并按拓扑顺序安装支持库。

Poetry 依据 pyproject.toml 管理项目内外的虚拟环境。

poetry.lock 文件可以确保项目的复用，但体积较大。此外，Poetry 还兼具构建工具功能，可以发布 Python 包。

Poetry 的解析速度较慢，部分是因为 Python 包声明支持库的方式不一致，可能会导致支持库解析的时间较长。

• 定位：现代依赖管理 + 打包工具（开源库开发首选）。全生命周期管理（依赖+打包+发布），基于pyproject.toml。
• 功能：一体化工具：集成了虚拟环境管理、依赖管理（pyproject.toml）和打包发布功能。
• 优点：语义化版本控制，动态依赖约束（如 ^1.2.3）。一体化工具链（开发到发布全流程）。一键发布PyPI，依赖树可视化。
• 缺点：冷启动解析较慢，自定义构建流程支持弱。 学习成本较高（需熟悉 pyproject.toml）。对旧项目迁移有一定成本。
• 场景：复杂项目、开源库开发、追求现代工作流。

# 安装poetry   
pip install poetry      
# 创建新项目   
poetry new myproject      
# 添加依赖   
poetry add requests      
# 进入虚拟环境   
poetry shell

3. PDM（Frost Ming，2020）

pdm GitHub

PDM 的目标是成为新生代 Python 支持库管理工具。

与 Poetry 类似，PDM 也是一款快速的支持库解析器，主要用于大型二进制文件分发。

它具备灵活强大的插件系统和多功能用户脚本。

此外，PDM 还可以使用 indygreg 的 python-build-standalone 安装 Python，并支持类似 pnpm 的集中式安装缓存。

PDM 与 Poetry 的主要区别在于，PDM 支持 PEP-582，将虚拟环境集成到项目目录中，避免了传统虚拟环境的手动激活和停用，提高了开发效率。

• 定位：PEP 582标准实践者，支持项目本地包目录，无需虚拟环境。
• 优点：依赖解析快，避免环境激活，兼容pyproject.toml。
• 缺点：IDE支持需额外配置，非虚拟环境模式调试复杂。
• 场景：追求轻量化的微服务、工具链开发。

4. Rye（Astral，2023）

Rye GitHub

Rye 由 Astral.sh 开发，也是基于 Rust 构建的，旨在提升开发效率和用户体验。与传统的包管理工具相比，Rye 的性能有显著提升，功能也更加丰富。

Rye 希望为 Python 开发者提供一站式的工具，让 Python 支持库的安装与管理更加轻松。

Rye 使用与 uv 相同的支持库解析器，提供更快的管理体验。

Rye 还提供了与 poetry 类似的功能，但速度更快。

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

5. uv（Astral，2024）

uv GitHub

uv 是一个由 Astral 开发的高性能 Python 包管理和项目管理工具，用 Rust 编写，旨在取代传统的 Python 工具（如 pip、virtualenv、poetry、甚至部分 pyenv 功能）。它以极快的速度和现代化的设计著称，号称比 pip 快 10-100 倍，比 Poetry 快 2-10 倍。uv 的目标是提供一个统一的、一站式的 Python 开发体验，涵盖包安装、虚拟环境管理、项目管理和 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环境的电脑上，只需使用命令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 虚拟环境管理器，是当前备受期待的新生代包管理工具。

uv 的目标是取代 pip，同时具备与 Cargo 类似的功能。

uv 支持 Python 打包工具的所有特性，包括可编辑安装、Git 依赖、URL 依赖、本地依赖、约束文件和源码分发等。

Astral.sh 还开发了 Rust 生态中备受开发者喜爱的 ruff （用 Rust 开发的高性能 Python 代码检查和代码格式化工具）。与 poetry 类似，uv 通过 pyproject.toml 管理项目，得益于 Rust 的高效算法，其解析速度至少比 poetry 快一个量级。

定位：新一代高性能 Python 工具，Rust编写的超高速一体化工具

功能：超高速包安装与依赖解析（兼容 pip 和 pip-tools 工作流）。支持虚拟环境管理（类似 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功能。

优点：

• 速度：依赖解析比pip快100倍（Jupyter项目冷启动500ms → 热缓存20ms）
• 全能：支持Python版本管理（uv python install）、依赖锁定（uv lock）、脚本执行（uv run）
• 安全：跨平台锁文件，哈希校验防篡改
• 跨平台：支持Windows、macOS和Linux。

缺点：生态适配中，暂不支持非Python依赖（如Conda的C++库）。

场景：所有纯Python项目的首选替代方案，尤其适合CI/CD流水线。

# 安装uv   
pip install uv      
# 创建虚拟环境   
uv venv myenv      
# 激活虚拟环境   
# Windows   
myenv\Scripts\activate   
# macOS/Linux   
source myenv/bin/activate      
# 退出虚拟环境   
deactivate

五、科学计算：非Python依赖管理

1. Conda（Anaconda团队，2012）

conda GitHub

conda 和 Anaconda 是两回事：

• conda 是包管理器（开源，BSD 许可证，仍然免费）。
• Anaconda 是一个商业公司提供的 Python 发行版，包括 conda、本地镜像源、大量预装包等。

从 2020 年起，Anaconda 公司对商业用途（如公司或机构）使用其官方发行版和镜像源实行了收费政策：

• 个人用户、开源项目、学术研究用途仍然免费。
• 企业用户如果通过 Anaconda 镜像或工具部署，需要购买许可证。

anaconda实在过于臃肿，它的安装包里包括了众多科学计算会用到的packages，安装后动辄5-6个G。

anaconda有个不包含packages的版本，叫miniconda，但miniconda仍然存在安装依赖库过于激进的问题，安装同样的packages，conda总会比别的包管理器安装更多的“依赖包”，即便有的“依赖包”并不是必须，这会导致你的项目出现不必要的膨胀。

同时，conda的packages列表“conda list”还存在和“pip list”不一致的问题。

Conda 是由 Anaconda 出品的命令行工具，用于在 Windows、macOS 和 Linux 上管理虚拟环境。它不仅能管理 Python 支持库，还能处理非 Python 支持库，尤其针对数据科学方面的开发进行了优化。

Conda 使用自己的 Conda 虚拟环境切换非 Python 依赖项，无需使用复杂的 Docker。与 Poetry 类似，Conda 在构建环境时执行完整的支持库解析，其支持库解析器 libmamba 是用 C++ 实现的，速度更快。

• 定位：跨语言包与环境管理（科学计算领域主流）。 （Python/R/CUDA）
• 功能：管理 Python 和非 Python 依赖（如 C/C++、R 库）。自带预编译包（优化科学计算库安装）。
• 优点：跨平台：支持Windows、macOS和Linux。一键安装SciPy栈，支持Python/R/CUDA等混合依赖，预编译加速科学库安装。
• 缺点：包更新滞后PyPI，虚拟环境切换慢。 环境体积臃肿（Miniconda>1GB） 。复杂依赖解析可能冲突。
• 场景：数据科学、机器学习、跨学科项目。

# 创建虚拟环境   
conda create -n myenv python=3.8      
# 激活虚拟环境   
conda activate myenv      
# 退出虚拟环境   
conda deactivate

2. Mamba（2019年）

mamba GitHub

是Conda的改进版，旨在解决Conda的痛点，如慢的依赖解析和并行下载问题，用 C++ 实现，使用不同算法，推荐安装方式已改变。
速度比Conda 快很多，其他方面和Conda类似。

3. Miniforge（conda-forge社区，2020）

miniforge GitHub

• 定位：Conda轻量替代版，默认conda-forge源
• 场景：数据科学轻量化部署

4. Pixi（Prefix.dev团队，2024）

pixi GitHub

Pixi 是基于 Rust 的 rattler 库开发的，具有显著的性能和安全优势。它的理念是提供类似于 cargo 或 yarn 的开发体验。

Pixi 目标是直接取代 Conda，并能像 Conda 一样管理非 Python 依赖项。

2024 年 2 月，为了追求更快的速度，Pixi 将后台的 rip 改为 uv。与 Conda 和 mamba 不同，Pixi 提供了自定义类型的锁文件，使其在复用方面领先于 Conda。

Pixi 支持可复用的方式安装支持库，并支持 Python、C++ 和 R 等多种语言， 且兼容所有主流操作系统。

Pixi 还提供了简洁而强大的命令行界面，使得支持库管理更加简单、高效。

• 定位：Conda的现代替代品，基于Rust构建。 ，支持pyproject.toml
• 优点：兼容Conda库且解析更快，支持pyproject.toml。 混合管理PyPI和Conda包，解析速度提升5倍
• 缺点：社区包覆盖不全。
• 场景：需混合PyPI和Conda包的跨语言工程。

六、依赖管理工具：专治版本混乱

1. pip-tools（Vincent Driessen团队，2013）

pip-tools GitHub

定位：生产级精准依赖锁定

核心命令：

• pip-compile：从.in文件生成带哈希的requirements.txt
• pip-sync：严格同步环境至锁定状态

场景：Docker镜像构建，生产服务器部署

2. pipreqs（社区，2016）

pipreqs GitHub

• 定位：基于项目import语句生成纯净requirements.txt。
• 神技：pipreqs /project --ignore node_modules --encoding=utf8
• 优点：自动忽略虚拟环境目录，支持--ignore排除无关路径。
• 缺点：无法识别动态导入（如__import__('os')）。
• 场景：从遗留项目重构依赖，生成最小化生产环境清单。

3. pigar（社区，2018）

pigar GitHub

• 定位：AST解析依赖，标注依赖在代码中的位置。
• 优点：精确识别跨版本标准库（如Py2的futures vs Py3的concurrent.futures）。
• 缺点：输出文件含位置注释，需手动清理后部署。
• 场景：审计依赖来源，解决“这个包到底在哪用？”的灵魂拷问。

# 输出带代码位置注释的requirements.txt
$ pigar -p /project -o requirements.txt

4. pipdeptree（社区，2015）

pipdeptree GitHub

• 定位：可视化依赖树与冲突检测。
• 优点：提示循环依赖，生成冲突报告（如pkgA需要numpy<2.0，pkgB需要numpy>=2.0）。
• 缺点：需在每个虚拟环境中单独安装。
• 场景：诊断依赖冲突，架构治理。

# 检测冲突示例
$ pipdeptree --warn conflict | grep "version conflict"

七、终极对比表：13款工具全景图

八、依赖管理工具时间简史

2000年，setuptools

Python2自2000年发布以来，语言尚未完全稳定和成型，最开始通过easy_install（2004 年发布，属于 setuptools 的一部分）从PyPI（2003 年上线）安装.egg格式的包。

2008年，pip+virtualenv

2008年，为了解决Python2中的一些设计缺陷和向后不兼容的问题，发布Python 3.0。随着社区的建设，PyPI的库越来越多，python官方发布了包管理工具pip用于从PyPI安装库，同样的，python的版本也在增多，不同版本之间库版本兼容不同，pip本身只是给全局环境直接安装一套一样的依赖，如果有两个项目依赖于同一个库的不同版本，你是不可能同时在全局环境里把这两个版本都装上的。为了避免冲突，最好是给每个项目都有一套独立的 pip 环境，分别安装各自需要的依赖，这个就是虚拟环境，第三方库率先发布了virtualenv实现环境管理。

2012年，venv

此时，包管理和环境管理工具为pip+virtualenv。2012年，Python3.3发布，内置了环境管理工具venv，内置的更高效和方便，就替代了virtualenv。你用 PyCharm 创建项目时，默认会用 venv 建一个虚拟环境，也就是你看到的 venv 文件夹，就是为了让每个项目都有独立的依赖，避免冲突。

2013年，pip-tools

venv 在简单的场景下大概足够了，你也可以直接进入虚拟环境导出 requirements.txt 或手写个 pyproject.toml 来声明依赖。但是你可能不太喜欢这种完全“手动挡”的模式，而是希望有一些更加方便的工具，可以让你直接输入一个 xxx-tool install 命令就直接检测项目目录下的 requirements.txt 或 pyproject.toml，利用里边写明的依赖自动生成一个虚拟环境，如果已经有虚拟环境就安装缺少的库/移除不再需要的库，然后使用 xxx-tool add lib1 这种命令就能自动更新 requirements.txt 或 pyproject.toml并自动在虚拟环境中安装 lib1。

于是2013年，社区发布了pip-tools，它提供两个命令：pip-compile 用于生成和操作依赖清单（requirements.txt，注意这个 requirements.txt 和 Python 旧标准中的同名文件所功能不一样，在 pip-tools 中它更类似于一个 lockfile），pip-sync 用于根据依赖清单将其内容与当前虚拟环境同步。但是 pip-tools 本身不会做更多事情了，它只聚焦于提供这两个命令——如果你需要添加/删除一个包或将某个包更新到与原本不兼容的版本，你需要先操作 pyproject.toml、使用 pip-compile 重新生成 requirements.txt，然后再用 pip-sync 同步进去。pip-tools 本身也只是同步当前的 pip 环境，不关心虚拟环境的事情，如果你要与 venv 一起使用，得先激活 venv 在里边操作 pip-tools 才行。

2014年，pyenv

随着python版本的更新，越来越多的开发者需要同时在不同的python版本下工作，手动切换总是很麻烦。社区在2014年发布了pyenv，pyenv 是一个纯Python版本管理工具（非依赖管理），pyenv 完全由纯 Shell 脚本实现，不依赖 Python。 主要用于管理多个 Python 版本，而不是直接管理包，但它可以用来设置特定版本的 Python 环境，进而使用其他包管理工具。

2017年，pipenv

目前开发工具集就是pip+venv+pip-tools+pyenv，虽然解决了需求，但是实际操作起来还是很麻烦。更复杂的是当你试图编写一个库并发布到 PyPI 的时候——此时你需要一个构建工具、一个打包工具和一个负责把包发布到 PyPI 的工具。如果你需要一套标准流程，全部利用 Python 文档中推荐的东西大概需要结合 setuptools + python -m build + Twine（分别负责构建、打包和发布到 PyPI）。

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

2018年，poetry

但pipenv并不稳定，2018年，社区发布了poetry，这是最早可用的现代化项目管理工具，基于pyproject.toml，进行全生命周期管理（依赖+打包+发布），是开源库开发的首选。

2020年，PDM

Poetry 的问题首先在于它并不完全符合标准，典型的如它默认的 pyproject.toml 格式不符合 PEP 621（尽管目前已有实验性支持）——因为 Poetry 的出现比 PEP 621 更早，自然不能未卜先知。另一个问题在于 Poetry 在解析依赖上的性能不尽如人意，一个 poetry add 常常需要花几十秒时间，这显然不够理想。
所以自然出现了“更符合标准”的工具，2020年，社区推出了PEP 582标准实践者PDM。

2023年，Rye

这些工具各有各的特点，也各有各的问题。首先是这些工具作为针对单个项目的依赖管理工具与构建工具，本身并不管理 Python 本身——许多用户是有客观的同时使用多个版本 Python 的需求的，有些人会用 pyenv 编译安装多个版本的 Python，有些人直接用包管理器切换 shims，有些人则直接使用 Conda——这个需求显然是这些项目管理工具做不到的；其次是工具安装的问题，有时我们会需要用 pip 安装一些命令行工具，比如 black 和 ruff，但直接使用 pip 安装到全局环境中很容易产生依赖冲突，也会污染全局依赖，所以有了 pipx 这样的项目用于为每个工具创建单独的隔离虚拟环境。

所以我们看到至少还有两个需求，即 pyenv 与 pipx 的任务可以进一步整合进来。2023年，Astral.sh大神发布了基于Rust的Rye，它不仅整合了 Poetry 的功能，也可以像 pyenv 或 Conda 一样在你的机器上管理多个 Python 版本、像 pipx 一样以隔离环境安装工具，也整合了 ruff 作为开箱即用的 Linter 和 Formatter，对 pytest 也提供了支持。Rye 实际上不像 Poetry/Hatch/PDM 一样实现了自己的依赖解析系统和构建后端，而只是将各种工具（uv/pip-tools、Hatchling、build、Twine 等）整合到一起，让它们能够协同工作，更近似一个“前端”项目。

2024年，uv

由于pip的速度较慢，Astral.sh于2024年2月发布了uv，一开始只是一个更快的包安装工具和依赖解析工具，用 Rust 编写，旨在作为 pip 和 pip-tools 性能更好的替代品。在发布之后Rye于同月把包管理由pip替换为了uv。

后来，rye的初始作者最近把项目移交给uv团队了, 相当于两个项目合并。在 0.3.0 (2024/08) 加入了 python 环境管理和项目管理。到现在，已经完全可以用uv替代Rye了。

至此，python的依赖管理工具终于迎来了短暂的终局，以后随着python的发展和社区的发展，可能会继续出现新的划时代的工具

科学计算

科学计算环境下，由于需要用到各种语言的库，是一个单独的领域，就统一说一下。

• 2012年，Conda/miniconda，跨语言包与环境管理（Python/R/CUDA）
• 2020年，Anaconda 收费后，conda-forge社区发布了Miniforge
• 2019年，Mamba，作为Conda的轻量级替代品
• 2024年，pixi，Conda的现代替代品，基于Rust构建。

九、2025年工具选型黄金法则

初学者或简单项目：先拿pip+venv练手，掌握基本原理

库开发者：坚持 Poetry（生态最成熟，PyPI发布无缝衔接）

数据科学： 传统是Conda，非Python依赖（如CUDA、MKL）必须靠它。 如果同时使用PyPI库和团队协作就用Pixi

Python2旧项目：Virtualenv管理环境，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已支持直接启动隔离容器环境，未来工具链将深度整合Docker。

以上就是Python中依赖管理工具使用终极指南(保姆级教程)的详细内容，更多关于Python依赖管理的资料请关注脚本之家其它相关文章！