如何管理Python项目的依赖？-Python教程-PHP中文网

答案：Python依赖管理核心在于隔离与精确控制，通过虚拟环境避免依赖冲突，结合pip、requirements.txt或更先进的Poetry、Rye等工具实现环境可复现；虚拟环境确保项目独立，现代工具如Poetry利用pyproject.toml和锁定文件提升依赖解析与一致性，处理复杂冲突时需版本锁定、工具辅助及合理策略。

如何管理python项目的依赖？

管理Python项目的依赖，说白了，就是确保你的代码能跑起来，而且在不同环境里也能跑得起来。这事儿的核心在于“隔离”与“精确控制”。我们通常会围绕虚拟环境，结合像

pip

登录后复制

、

requirements.txt

登录后复制

这样的基础工具，或者更现代、更强大的解决方案如

Poetry

登录后复制

、

Rye

登录后复制

，来构建一个健壮、可复现的开发和部署流程。它不仅仅是装包卸包那么简单，更是项目健康和团队协作的关键。

解决方案

在我看来，管理Python项目依赖，首先得从理解其必要性开始。想想看，你的机器上可能同时跑着好几个Python项目，每个项目需要的

Django

登录后复制

、

requests

登录后复制

或

pandas

登录后复制

版本可能都不一样。如果都直接往系统Python里装，那简直就是自找麻烦，迟早会陷入“依赖地狱”。所以，虚拟环境是第一道也是最重要的一道防线。

一旦有了隔离的环境，接下来就是如何声明和安装这些依赖。最常见也最基础的方式就是使用

pip

登录后复制

和

requirements.txt

登录后复制

。当你确定了项目所需的所有包及其版本后，

pip freeze > requirements.txt

登录后复制

就能帮你记录下来。之后，其他人或者你在部署时，只需

pip install -r requirements.txt

登录后复制

，就能快速复现这个环境。这里有个小技巧，我个人倾向于在

requirements.txt

登录后复制

中精确锁定版本（例如

requests==2.28.1

登录后复制

），而不是使用模糊的版本范围（如

requests>=2.28

登录后复制

），这样能最大程度避免未来因为某个库更新而导致的不兼容问题。虽然这有时会让更新依赖变得麻烦一些，但为了项目的稳定性，这点“麻烦”是值得的。

当然，

pip

登录后复制

和

requirements.txt

登录后复制

并非完美无缺，它在处理复杂依赖图、锁定传递性依赖（即你安装的包A又依赖包B，包B又依赖包C……）时，会显得力不从心。这也是为什么后来出现了像Poetry、PDM、Rye这些更高级的工具。它们通常采用

pyproject.toml

登录后复制

文件来统一管理项目元数据、依赖，甚至构建系统。这些工具内置了更智能的依赖解析器，能够自动处理传递性依赖，并生成一个锁定文件（如

poetry.lock

登录后复制

），确保每次安装都能得到完全一致的环境。我个人的经验是，一旦你的项目规模稍大，或者需要频繁地添加/删除依赖，转向这些工具会大大提升开发效率和项目的可维护性。它们让“可复现性”从一个美好的愿望变成了实实在在的保障。

立即学习“Python免费学习笔记（深入）”；

为什么虚拟环境是Python依赖管理的核心？

当你开始接触Python项目开发时，可能很快就会听到“虚拟环境”这个词。为什么它如此重要，甚至可以说是Python依赖管理的基石？这背后其实是一个非常朴素但深刻的道理：隔离与避免冲突。

想象一下，你的电脑上只有一个全局的Python环境。你为项目A安装了

Django 2.2

登录后复制

，又为项目B安装了

Django 3.2

登录后复制

。这时，系统会怎么处理？它会覆盖掉旧的版本，或者干脆报错。结果就是，项目A可能跑不起来了，或者项目B也因为版本冲突而崩溃。这种情景就是所谓的“依赖地狱”（Dependency Hell），相信每个开发者都或多或少经历过。

虚拟环境，比如

venv

登录后复制

模块创建的，或者通过

conda

登录后复制

、

virtualenv

登录后复制

等工具生成的，本质上是在你的项目目录下创建一个独立的、轻量级的Python运行环境。这个环境有自己独立的

site-packages

登录后复制

目录，所有你为该项目安装的库都会被安装到这里，而不会影响到全局Python环境或其他项目的虚拟环境。

它的好处是显而易见的：

完全隔离： 每个项目都有自己的依赖集，互不干扰。你可以在一个项目里用
```
Django 2.x
```
登录后复制
，在另一个项目里用
```
Django 4.x
```
登录后复制
，它们都能和谐共存。
环境可复现： 当你把项目分享给团队成员或者部署到服务器时，只需分享
```
requirements.txt
```
登录后复制
或
```
pyproject.toml
```
登录后复制
，配合虚拟环境，就能保证大家都在一个完全一致的运行环境中工作。这大大减少了“在我的机器上能跑”的尴尬。
整洁与安全： 避免了向系统全局Python环境安装大量不必要的包，保持了系统的整洁。同时，也降低了因全局环境被破坏而导致所有项目受影响的风险。
版本控制友好： 虚拟环境本身通常不被纳入版本控制（
```
.gitignore
```
登录后复制
会忽略它），但其依赖列表（如
```
requirements.txt
```
登录后复制
）会，这使得依赖管理更加清晰。

我个人的习惯是，每开一个新项目，第一件事就是

python -m venv .venv

登录后复制

，然后

source .venv/bin/activate

登录后复制

。这已经成了我的肌肉记忆。虽然偶尔会忘记激活，导致包装到了全局环境，但很快就能发现并纠正。这种习惯的养成，能从源头上避免很多潜在的依赖问题，让你的开发体验顺畅很多。

pip之外，还有哪些现代Python依赖管理工具值得关注？

pip

登录后复制

和

requirements.txt

登录后复制

无疑是Python世界里最普及、最基础的依赖管理方式，但它们并非没有局限。尤其是当项目规模增大、依赖关系变得复杂时，你可能会开始感到力不从心。这时，一些更现代、更智能的工具就显得非常有吸引力了。我个人在多个项目中尝试过这些工具，发现它们确实能解决

pip

登录后复制

的一些痛点。

Poetry 是其中一个非常受欢迎的选择。它不仅仅是一个依赖管理器，更是一个完整的Python项目管理工具。Poetry的核心理念是：将项目的所有元数据（包括依赖）统一放在

pyproject.toml

登录后复制

文件中。它解决了

pip

登录后复制

在处理传递性依赖时的一些不足，例如：

智能依赖解析： Poetry拥有一个强大的依赖解析器，能自动找出所有直接和间接依赖的最佳兼容版本，避免版本冲突。这对于大型项目尤其重要。
锁定文件（
poetry.lock
登录后复制
）：每次安装或更新依赖后，Poetry都会生成一个
```
poetry.lock
```
登录后复制
文件，精确记录了每个包及其所有传递性依赖的准确版本。这意味着无论何时何地，只要使用
```
poetry install
```
登录后复制
，就能复现出完全相同的环境。这比
```
requirements.txt
```
登录后复制
更具确定性。
统一的项目配置：
```
pyproject.toml
```
登录后复制
不仅管理依赖，还能配置项目的构建系统、脚本、测试等，使得项目结构更清晰。
内置虚拟环境管理： Poetry可以自动为项目创建和管理虚拟环境，你甚至不需要手动激活，它会智能地在项目上下文中运行命令。

使用Poetry的流程通常是：

poetry new my-project

登录后复制

创建项目，

poetry add requests

登录后复制

添加依赖，

poetry install

登录后复制

安装依赖，

poetry run python my_script.py

登录后复制

运行脚本。它的

add

登录后复制

和

remove

登录后复制

命令会自动更新

pyproject.toml

登录后复制

和

poetry.lock

登录后复制

，非常方便。

乾坤圈新媒体矩阵管家

新媒体账号、门店矩阵智能管理系统

查看详情

除了Poetry，还有一些其他值得一提的工具：

PDM (Python Development Master): PDM是另一个现代的Python包管理器，它也使用
```
pyproject.toml
```
登录后复制
来管理依赖，并支持PEP 582（一种新的本地包安装方案，无需虚拟环境），虽然PEP 582还在实验阶段，但PDM的理念和功能与Poetry有很多相似之处，它也提供了强大的依赖解析和锁定功能。
Rye: 由Rust编写，旨在成为一个快速、可靠的Python版本和包管理工具。Rye的特点是速度快，而且它试图简化Python环境的管理，让你无需手动管理虚拟环境，它会为你处理这些细节。它也使用
```
pyproject.toml
```
登录后复制
，并提供类似Poetry的依赖锁定机制。

选择哪个工具，很大程度上取决于你的项目需求、团队偏好以及你对新工具的接受度。对于新项目，我个人现在倾向于直接使用Poetry，因为它在社区中成熟度高，文档完善，并且提供了一站式的项目管理体验。对于旧项目，如果迁移成本太高，继续使用

pip

登录后复制

和

requirements.txt

登录后复制

辅以

pip-tools

登录后复制

（一个能帮助生成锁定版本的

requirements.txt

登录后复制

的工具）也是一个不错的折衷方案。

处理复杂的依赖冲突：实用策略与工具

依赖冲突是Python项目开发中一个令人头疼的问题。当你的项目直接或间接依赖的两个或多个库，对同一个子依赖有不同的版本要求时，冲突就产生了。比如，A库需要

requests==2.20.0

登录后复制

，而B库需要

requests==2.25.0

登录后复制

，

pip

登录后复制

在安装时就可能不知道该怎么办，或者安装了一个版本导致另一个库无法正常工作。面对这种“剪不断理还乱”的局面，我总结了一些实用策略和工具。

1. 精确版本锁定：预防是最好的治疗

这是最基础也最重要的策略。在

requirements.txt

登录后复制

中，始终使用精确的版本号（例如

requests==2.28.1

登录后复制

），而不是范围（

requests>=2.28

登录后复制

）。虽然这在初期可能需要你手动更新版本，但能极大地减少未来冲突的发生。当使用Poetry等工具时，

poetry.lock

登录后复制

文件就是为你做了这件事，它锁定了所有直接和传递性依赖的精确版本。

2. 理解冲突信息：不要盲目尝试

当

pip

登录后复制

或Poetry报错时，仔细阅读错误信息至关重要。它们通常会告诉你哪个库需要哪个版本的哪个依赖，以及与哪个现有依赖冲突。例如，

pip

登录后复制

可能会提示

ERROR: Cannot install package_A==1.0 because package_B==2.0 requires package_A<1.0

登录后复制

。这些信息是解决问题的关键线索。

3. 逐步降级或升级：找到兼容点

降级策略： 如果一个新引入的库导致了冲突，尝试将其版本降级到更旧、更稳定的版本，直到找到一个与现有依赖兼容的版本。
升级策略： 有时，冲突是因为某个旧库的版本太老。尝试升级项目中的所有主要依赖到最新版本，这可能会让它们之间的依赖关系变得更协调。但请注意，这可能引入新的不兼容性，需要仔细测试。

4. 使用依赖解析工具：让工具帮你思考

pip-tools
登录后复制
：如果你仍然使用
```
pip
```
登录后复制
和
```
requirements.txt
```
登录后复制
，
```
pip-tools
```
登录后复制
是一个非常棒的辅助工具。它通过
```
pip-compile
```
登录后复制
命令读取
```
requirements.in
```
登录后复制
文件（只列出你直接依赖的包和大致版本），然后自动解析所有传递性依赖，并生成一个精确锁定的
```
requirements.txt
```
登录后复制
文件。它比手动管理要智能得多，也能更好地处理冲突。
Poetry/PDM/Rye： 这些现代工具内置了强大的依赖解析器。当遇到冲突时，它们通常会给出更详细的报告，并尝试找到一个可行的解决方案。如果它们无法解决，通常是因为确实没有兼容的版本组合。这时，你可能需要手动调整
```
pyproject.toml
```
登录后复制
中的依赖版本，或者考虑替换冲突的库。