目录
- 前言1
- 前言2
- 一、包管理工具
-
- [1. pip(Python官方,2008)](#1. pip(Python官方,2008))
- 二、虚拟环境工具
-
- [1. virtualenv(Ian Bicking,2007)](#1. virtualenv(Ian Bicking,2007))
- [2. venv(Python3.3,2012)](#2. venv(Python3.3,2012))
- 三、版本管理工具
-
- [1. pyenv(社区开发,2014)](#1. pyenv(社区开发,2014))
- 四、项目管理工具:依赖+环境+打包三位一体
-
- [1. Pipenv(Kenneth Reitz,2017)](#1. Pipenv(Kenneth Reitz,2017))
- [2. Poetry(Sébastien Eustace,2018):现代Python项目的全能选手](#2. Poetry(Sébastien Eustace,2018):现代Python项目的全能选手)
- [3. PDM(Frost Ming,2020)](#3. PDM(Frost Ming,2020))
- [4. Rye(Astral,2023)](#4. Rye(Astral,2023))
- [5. uv(Astral,2024): Rust高性能工具链,新王登基](#5. uv(Astral,2024): Rust高性能工具链,新王登基)
- 五、科学计算:非Python依赖管理
-
- [1. Conda(Anaconda团队,2012)](#1. Conda(Anaconda团队,2012))
- [2. Mamba(2019年)](#2. Mamba(2019年))
- [3. Miniforge(conda-forge社区,2020)](#3. Miniforge(conda-forge社区,2020))
- [4. Pixi(Prefix.dev团队,2024)](#4. Pixi(Prefix.dev团队,2024))
- 六、依赖管理工具:专治版本混乱
-
- [1. pip-tools(Vincent Driessen团队,2013)](#1. pip-tools(Vincent Driessen团队,2013))
- [2. pipreqs(社区,2016)](#2. pipreqs(社区,2016))
- [3. pigar(社区,2018)](#3. pigar(社区,2018))
- [4. pipdeptree(社区,2015)](#4. pipdeptree(社区,2015))
- 七、终极对比表:13款工具全景图
- 八、依赖管理工具时间简史
-
- [0. 2000年,setuptools](#0. 2000年,setuptools)
- [1. 2008年,pip+virtualenv](#1. 2008年,pip+virtualenv)
- [2. 2012年,venv](#2. 2012年,venv)
- [3. 2013年,pip-tools](#3. 2013年,pip-tools)
- [4. 2014年,pyenv](#4. 2014年,pyenv)
- [5. 2017年,pipenv](#5. 2017年,pipenv)
- [6. 2018年,poetry](#6. 2018年,poetry)
- [7. 2020年,PDM](#7. 2020年,PDM)
- [8. 2023年,Rye](#8. 2023年,Rye)
- [9. 2024年,uv](#9. 2024年,uv)
- [10. 科学计算](#10. 科学计算)
- 九、2025年工具选型黄金法则
- 后记
- 官网聚合
- 参考文献
前言1
在 Python 开发中,虚拟环境和包管理工具是必不可少的。它们可以帮助我们更好地管理项目依赖,避免环境冲突,提高开发效率。但是依赖管理堪称"头号工程难题"------环境冲突、版本不一致、部署失败等问题层出不穷。
由于Python的库发展的非常快,工具也是日新月异,搜索会发现有pip,venv、Virtualenv、Conda、Pipenv、Poetry、UV等等,你是否能把它们完全分清楚?
本文全面梳理解析截至目前的所有主流依赖工具,并分类介绍,涵盖基础工具、现代解决方案与新兴神器,助你精准选择最适合项目的武器库!
前言2
在深入对比之前,我们先明确虚拟环境和包管理工具的核心作用:
包管理 :管理项目的依赖包,包括安装、更新、卸载等操作,并确保依赖关系的一致性。
虚拟环境:为每个项目创建一个独立的Python运行环境,隔离依赖,避免不同项目之间的包版本冲突。
一、包管理工具
1. pip(Python官方,2008)
- 定位 :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)
旧时代的产物,除非还在使用python 2。
- 定位:第三方虚拟环境工具(支持Python 2/3)
- 功能:创建隔离环境,支持指定不同 Python 解释器。依赖 pip 管理包。
- 优点 :支持旧版 Python(如 Python 2)。可指定任意Python解释器,支持
--system-site-packages
复用系统包 。 - 缺点:需额外安装,Windows兼容性较弱 。依赖管理需手动处理。无自动依赖解析。
- 场景:遗留Python 2项目维护,多解释器版本测试。
python
# 安装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
# 创建虚拟环境
python -m venv myenv
# 激活虚拟环境
# Windows
myenv\Scripts\activate
# macOS/Linux
source myenv/bin/activate
# 退出虚拟环境
deactivate
三、版本管理工具
1. pyenv(社区开发,2014)
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)
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支持,优化依赖解析逻辑。
python
# 安装pipenv
pip install pipenv
# 创建虚拟环境并安装依赖
pipenv install
# 激活虚拟环境
pipenv shell
# 退出虚拟环境
exit
2. Poetry(Sébastien Eustace,2018):现代Python项目的全能选手
- 在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)。对旧项目迁移有一定成本。
- 场景:复杂项目、开源库开发、追求现代工作流。
python
# 安装poetry
pip install poetry
# 创建新项目
poetry new myproject
# 添加依赖
poetry add requests
# 进入虚拟环境
poetry shell
3. PDM(Frost Ming,2020)
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 由 Astral.sh 开发,也是基于 Rust 构建的,旨在提升开发效率和用户体验。
与传统的包管理工具相比,Rye 的性能有显著提升,功能也更加丰富。
Rye 希望为 Python 开发者提供一站式的工具,让 Python 支持库的安装与管理更加轻松。
Rye 使用与 uv 相同的支持库解析器,提供更快的管理体验。
Rye 还提供了与 poetry 类似的功能,但速度更快。
- 定位:Poetry的极速替代品,共享uv解析引擎
5. uv(Astral,2024): Rust高性能工具链,新王登基
- 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项目):
工具 冷启动时间 热缓存时间 pip 32.1s 28.7s Poetry 11.4s 9.2s uv 0.5s 0.02s -
命令全景:
bashuv 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流水线。
python
# 安装uv
pip install uv
# 创建虚拟环境
uv venv myenv
# 激活虚拟环境
# Windows
myenv\Scripts\activate
# macOS/Linux
source myenv/bin/activate
# 退出虚拟环境
deactivate
五、科学计算:非Python依赖管理
1. Conda(Anaconda团队,2012)
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) 。复杂依赖解析可能冲突。
- 场景:数据科学、机器学习、跨学科项目。
python
# 创建虚拟环境
conda create -n myenv python=3.8
# 激活虚拟环境
conda activate myenv
# 退出虚拟环境
conda deactivate
2. Mamba(2019年)
是Conda的改进版,旨在解决Conda的痛点,如慢的依赖解析和并行下载问题,用 C++ 实现,使用不同算法,推荐安装方式已改变。
速度比Conda 快很多,其他方面和Conda类似。
3. Miniforge(conda-forge社区,2020)
- 定位:Conda轻量替代版,默认conda-forge源
- 场景:数据科学轻量化部署
4. Pixi(Prefix.dev团队,2024)
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-compile
:从.in
文件生成带哈希的requirements.txt
pip-sync
:严格同步环境至锁定状态
- 场景:Docker镜像构建,生产服务器部署
2. pipreqs(社区,2016)
- 定位 :基于项目import语句生成纯净
requirements.txt
。 - 神技 :
pipreqs /project --ignore node_modules --encoding=utf8
- 优点 :自动忽略虚拟环境目录,支持
--ignore
排除无关路径。 - 缺点 :无法识别动态导入(如
__import__('os')
)。 - 场景:从遗留项目重构依赖,生成最小化生产环境清单。
3. pigar(社区,2018)
- 定位:AST解析依赖,标注依赖在代码中的位置。
- 优点 :精确识别跨版本标准库(如Py2的
futures
vs Py3的concurrent.futures
)。 - 缺点:输出文件含位置注释,需手动清理后部署。
- 场景:审计依赖来源,解决"这个包到底在哪用?"的灵魂拷问。
bash
# 输出带代码位置注释的requirements.txt
$ pigar -p /project -o requirements.txt
4. pipdeptree(社区,2015)
- 定位:可视化依赖树与冲突检测。
- 优点 :提示循环依赖,生成冲突报告(如
pkgA需要numpy<2.0,pkgB需要numpy>=2.0
)。 - 缺点:需在每个虚拟环境中单独安装。
- 场景:诊断依赖冲突,架构治理。
bash
# 检测冲突示例
$ pipdeptree --warn conflict | grep "version conflict"
七、终极对比表:13款工具全景图
工具 | 作者/团队 | 发布时间 | 定位 | 环境隔离 | Python版本安装 | 依赖声明文件 | 依赖解析器复杂度 | 锁文件生成 | 跨平台锁文件 | 非Python依赖管理 | pyproject.toml 原生支持 |
包构建 | 包发布 | CLI工具安装 | Monorepo支持 | 实现语言 | 主要缺点 | 典型适用场景 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
pip | Python官方 | 2008 | 基础包安装器 | ❌ | ❌ | requirements.txt |
低(无冲突解决) | ❌ | ❌ | ❌ | ⚠️部分支持 | ❌ | ❌ | ❌ | ❌ | Python | 无依赖解析、无环境隔离 | 临时安装/底层引擎 |
virtualenv | Ian Bicking | 2007 | 跨版本环境隔离 | ✅ | ❌ | 无 | 无 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | Python | 无依赖管理功能,需配合pip | Python 2兼容/多解释器测试 |
venv | Python官方 | 2012 | 轻量级环境隔离 | ✅ | ❌ | 无 | 无 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | Python | 无法管理Python版本 | Python 3小型项目快速隔离 |
pyenv | Yasushi Saito | 2010 | 解释器版本管理 | ❌ | ✅ | 无 | 无 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | Bash/Python | 无依赖管理功能 | 多Python版本切换 |
pipenv | Kenneth Reitz | 2017 | 环境+依赖整合 | ✅ | ❌ | Pipfile |
中(速度慢) | Pipfile.lock |
✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | Python | 依赖解析不稳定,锁文件偶发不一致 | 中小型Web应用 |
poetry | Sébastien Eustace | 2019 | 全生命周期管理 | ✅ | ❌ | pyproject.toml |
高(严格策略) | poetry.lock |
✅ | ❌ | ✅ | ✅ | ✅ | ❌ | ⚠️基础 | Python | 冷启动慢,国内镜像需逐项目设置 | 开源库开发/复杂依赖项目 |
pdm | Frost Ming | 2020 | PEP 582项目本地包目录 | ⚠️(可选) | ❌ | pyproject.toml |
高 | pdm.lock |
✅ | ❌ | ✅ | ✅ | ✅ | ✅ | ⚠️基础 | Python | IDE需手动配置解释器路径 | 微服务/CLI工具开发 |
rye | Armin Ronacher | 2023 | 极速Poetry替代品 | ✅ | ✅ | pyproject.toml |
极高(Rust引擎) | requirements.lock |
✅ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | Rust | 较新,生态适配中 | 追求速度的现代项目 |
uv | Astral | 2024 | 超高速一体化工具链 | ✅ | ✅ | pyproject.toml |
极高(Rust引擎) | uv.lock |
✅ | ❌ | ✅ | ✅ | ✅ | ✅ (uv tool ) |
✅ | Rust | 不支持非Python依赖(如C++库) | 所有纯Python项目 |
conda | Anaconda | 2012 | 科学计算生态 | ✅ | ✅ | environment.yml |
中(跨语言解析) | 无标准锁文件 | ❌ | ✅ | ⚠️部分支持 | ⚠️有限 | ⚠️有限 | ❌ | ❌ | Python | 环境臃肿,包更新滞后PyPI | 数据科学/AI工程 |
mamba | QuantStack | 2019 | Conda加速版 | ✅ | ✅ | environment.yml |
高(C++引擎) | 无标准锁文件 | ❌ | ✅ | ⚠️部分支持 | ⚠️有限 | ⚠️有限 | ❌ | ❌ | C++ | 命令行兼容性偶有问题 | 大型科学计算项目 |
Miniforge | conda-forge社区 | 2020 | Conda轻量版 | ✅ | ✅ | environment.yml |
中 | 无标准锁文件 | ❌ | ✅ | ⚠️部分支持 | ⚠️有限 | ⚠️有限 | ❌ | ❌ | Python | 社区包覆盖不全 | 数据科学轻量化部署 |
pixi | 前缀树科技 | 2024 | Conda现代化替代 | ✅ | ✅ | pyproject.toml |
高(Rust引擎) | pixi.lock |
✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | Rust | 社区包覆盖不全 | 跨语言科学计算 |
八、依赖管理工具时间简史
0. 2000年,setuptools
Python2
自2000年发布以来,语言尚未完全稳定和成型,最开始通过easy_install
(2004 年发布,属于 setuptools 的一部分)从PyPI
(2003 年上线)安装.egg
格式的包。
1. 2008年,pip+virtualenv
2008年,为了解决Python2
中的一些设计缺陷和向后不兼容的问题,发布Python 3.0
。随着社区的建设,PyPI的库越来越多,python官方发布了包管理工具pip
用于从PyPI安装库,同样的,python的版本也在增多,不同版本之间库版本兼容不同,pip本身只是给全局环境直接安装一套一样的依赖,如果有两个项目依赖于同一个库的不同版本,你是不可能同时在全局环境里把这两个版本都装上的。为了避免冲突,最好是给每个项目都有一套独立的 pip 环境,分别安装各自需要的依赖,这个就是虚拟环境,第三方库率先发布了virtualenv
实现环境管理。
2. 2012年,venv
此时,包管理和环境管理工具为pip+virtualenv
。2012年,Python3.3
发布,内置了环境管理工具venv
,内置的更高效和方便,就替代了virtualenv
。你用 PyCharm 创建项目时,默认会用 venv 建一个虚拟环境,也就是你看到的 venv 文件夹,就是为了让每个项目都有独立的依赖,避免冲突。
3. 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 才行。
4. 2014年,pyenv
随着python版本的更新,越来越多的开发者需要同时在不同的python版本下工作,手动切换总是很麻烦。社区在2014年发布了pyenv
,pyenv 是一个纯Python版本管理工具(非依赖管理),pyenv 完全由纯 Shell 脚本实现,不依赖 Python。 主要用于管理多个 Python 版本,而不是直接管理包,但它可以用来设置特定版本的 Python 环境,进而使用其他包管理工具。
5. 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 官方曾推荐的依赖管理工具。
6. 2018年,poetry
但pipenv并不稳定,2018年,社区发布了poetry
,这是最早可用的现代化项目管理工具,基于pyproject.toml
,进行全生命周期管理(依赖+打包+发布),是开源库开发的首选。
7. 2020年,PDM
Poetry 的问题首先在于它并不完全符合标准,典型的如它默认的 pyproject.toml 格式不符合 PEP 621(尽管目前已有实验性支持)------因为 Poetry 的出现比 PEP 621 更早,自然不能未卜先知。另一个问题在于 Poetry 在解析依赖上的性能不尽如人意,一个 poetry add 常常需要花几十秒时间,这显然不够理想。
所以自然出现了"更符合标准"的工具,2020年,社区推出了PEP 582标准实践者PDM
。
8. 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 等)整合到一起,让它们能够协同工作,更近似一个"前端"项目。
9. 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的发展和社区的发展,可能会继续出现新的划时代的工具
10. 科学计算
科学计算环境下,由于需要用到各种语言的库,是一个单独的领域,就统一说一下。
- 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。
官网聚合
pypa Github
pip GitHub
virtualenv GitHub
pyenv GitHub
pipenv GitHub
poetry GitHub
pdm GitHub
Rye GitHub
uv GitHub
conda GitHub
mamba GitHub
miniforge GitHub
pixi GitHub
pip-tools GitHub
pipreqs GitHub
pigar GitHub
pipdeptree GitHub
参考文献
Python环境管理大比拼:venv、Virtualenv、Conda、Pipenv、Poetry、UV,如何选择,全在这里了?
Python虚拟环境和包管理,到底怎么选?
pip、venv、pipenv、poetry、conda、uv的区别
好学编程:11款Python虚拟环境管理器详细攻略,总有一款适合你!
从混沌到秩序:Python的依赖管理工具分析
写 Python 时,你是会选择 venv、Conda、Poetry 还是 Rye ?
rye 与 uv 的功能演化概述
喜欢的点个关注吧><!祝你永无bug~
txt
/*
_ooOoo_
o8888888o
88" . "88
(| -_- |)
O\ = /O
____/`---'\____
.' \\| |// `.
/ \\||| : |||// \
/ _||||| -:- |||||- \
| | \\\ - /// | |
| \_| ''\---/'' | |
\ .-\__ `-` ___/-. /
___`. .' /--.--\ `. . __
."" '< `.___\_<|>_/___.' >'"".
| | : `- \`.;`\ _ /`;.`/ - ` : | |
\ \ `-. \_ __\ /__ _/ .-` / /
======`-.____`-.___\_____/___.-`____.-'======
`=---='
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
佛祖保佑 永无BUG
*/