一、快速使用
| 功能 | 命令 | 说明 |
|---|---|---|
| 安装 | pip install pipdeptree | 安装 pipdeptree 工具 |
| 查看完整依赖树 | pipdeptree | 显示当前环境的完整依赖树状结构 |
| 反向查询依赖 | pipdeptree --reverse 或 pipdeptree -r | 显示每个包被哪些包所依赖 |
| 检查指定包依赖 | pipdeptree --packages <包名> | 只显示指定包的依赖关系 |
| 生成json格式 | pipdeptree --json | 以json格式输出依赖信息 |
| 抑制警告信息 | pipdeptree --warn silence | 不显示冲突警告信息 |
| 冲突时失败退出 | pipdeptree --warn fail | 发现冲突时以非零状态退出 |
二、常见问题
在python开发中,我们使用虚拟环境安装依赖时常遇到依赖冲突,查遍各个官方文档寻找版本对应关系,解决一个依赖问题,又跳出另一个依赖问题。
这么多第三方库各自又有复杂的依赖树,让人头大:
- 版本冲突:库a需要
requests>=2.25.0,而库b坚持使用requests==2.24.0。 - 隐式依赖:不知道
pandas背后还依赖着numpy,pytz,python-dateutil等一堆库。 - 依赖冗余:多个库依赖了同一个库的不同版本,导致环境臃肿且难以管理。
三、pipdeptree的原理与功能
pip 自带的 pip list 或 pip freeze 只能给出一个扁平的、按字母顺序排列的已安装包列表,完全无法展示其内在的层次关系。这里要介绍的是另一个工具:pipdeptree
pipdeptree 是一个命令行工具,它能分析当前python环境中已安装的包,并以树形结构直观地展示所有包之间的依赖关系。它不是包管理器,而是一个依赖关系分析器和可视化工具。
pipdeptree 的核心功能是回答两个关键问题:
- 这个包被谁所需要? (反向查询)
- 这个包又依赖了哪些包? (正向查询)
通过回答这些问题,它将一个平面的依赖列表转化为一幅清晰的“族谱”,整个项目的依赖状况一目了然。
1. 安装
pipdeptree 本身就是一个python包,可以通过pip安装:
pip install pipdeptree
2. 基本依赖树展示
在命令行直接输入 pipdeptree,它会打印出当前激活的虚拟环境下所有包的依赖树。
... ├── flask [required: >=1.1.1, installed: 2.2.5] │ ├── click [required: >=8.0, installed: 8.1.8] │ │ ├── colorama [required: any, installed: 0.4.6] │ │ └── importlib-metadata [required: any, installed: 6.7.0] │ │ ├── typing-extensions [required: >=3.6.4, installed: 4.7.1] │ │ └── zipp [required: >=0.5, installed: 3.15.0] │ ├── importlib-metadata [required: >=3.6.0, installed: 6.7.0] │ │ ├── typing-extensions [required: >=3.6.4, installed: 4.7.1] │ │ └── zipp [required: >=0.5, installed: 3.15.0] │ ├── itsdangerous [required: >=2.0, installed: 2.1.2] │ ├── jinja2 [required: >=3.0, installed: 3.1.5] │ │ └── markupsafe [required: >=2.0, installed: 2.1.5] │ └── werkzeug [required: >=2.2.2, installed: 2.2.3] │ └── markupsafe [required: >=2.1.1, installed: 2.1.5] ...
可以看到 flask 依赖 jinja2,而 jinja2 又依赖 markupsafe。
同时,werkzeug 也依赖了 markupsafe。这清晰地展示了共享依赖的情况。
3. 反向查询(找出为什么安装了一个包)
使用 --reverse (或 -r)标志。当你看到一个不熟悉的包时,可以用它来追溯其来源。
pipdeptree --reverse
部分输出示例:
... │ ├── jinja2 [required: >=3.0, installed: 3.1.5] │ │ └── markupsafe [required: >=2.0, installed: 2.1.5] │ └── werkzeug [required: >=2.2.2, installed: 2.2.3] │ └── markupsafe [required: >=2.1.1, installed: 2.1.5] ...
这表示 markupsafe 之所以被安装,是因为它是 jinja2 和 werkzeug 的依赖项。
或指定包:
pipdeptree --reverse --packages markupsafe
4. 将依赖树输出为文件
使用 --packages 参数可以只显示最顶层的“父”依赖(即你显式安装的包),这非常适合生成一个精简的 requirements.txt 文件。
先查下 flask:
pipdeptree --packages flask
输出:
flask==2.2.5 ├── click [required: >=8.0, installed: 8.1.8] │ ├── colorama [required: any, installed: 0.4.6] │ └── importlib-metadata [required: any, installed: 6.7.0] │ ├── typing-extensions [required: >=3.6.4, installed: 4.7.1] │ └── zipp [required: >=0.5, installed: 3.15.0] ├── importlib-metadata [required: >=3.6.0, installed: 6.7.0] │ ├── typing-extensions [required: >=3.6.4, installed: 4.7.1] │ └── zipp [required: >=0.5, installed: 3.15.0] ├── itsdangerous [required: >=2.0, installed: 2.1.2] ├── jinja2 [required: >=3.0, installed: 3.1.5] │ └── markupsafe [required: >=2.0, installed: 2.1.5] └── werkzeug [required: >=2.2.2, installed: 2.2.3] └── markupsafe [required: >=2.1.1, installed: 2.1.5]
同时查看多个包的依赖并输出至文件:
pipdeptree --warn silence --packages flask requests > log.txt
--warn silence用于抑制警告输出(如冲突警告),在只想安静地获取依赖树时用。--warn fail则会在发现冲突时以非零状态退出。
提取所有顶层包(注意windows用不了grep ):
pipdeptree --warn silence | grep -e '^\w+'
提取所有顶层包输出到文件:
pipdeptree --warn silence | grep -e '^\w+' > requirements.txt
5. 发现冲突与问题
pipdeptree 默认会检查依赖冲突。如果环境中存在无法同时满足的版本要求,它会以 警告(warning) 的形式高亮显示这些冲突。
warning!!! possibly conflicting dependencies found: * celery==5.2.7 -> click-didyoumean>=0.0.1,<0.1.0 * click-repl==0.2.0 -> click<9.0.0,>=7.0
这通常是依赖地狱的第一个信号,快点手动干预吧ㄒoㄒ~。
6. json输出
使用 --json 或 --json-tree 标志可以以机器可读的json格式输出结果,便于与其他工具(如自动化脚本、ci/cd流水线)集成。
pipdeptree --json
输出:
...
{
"package": {
"key": "flask",
"package_name": "flask",
"installed_version": "3.1.2"
},
"dependencies": [
{
"key": "blinker",
"package_name": "blinker",
"installed_version": "1.9.0",
"required_version": ">=1.9.0"
},
{
"key": "click",
"package_name": "click",
"installed_version": "8.2.1",
"required_version": ">=8.1.3"
},
{
"key": "itsdangerous",
"package_name": "itsdangerous",
"installed_version": "2.2.0",
"required_version": ">=2.2.0"
},
{
"key": "jinja2",
"package_name": "jinja2",
"installed_version": "3.1.6",
"required_version": ">=3.1.2"
},
{
"key": "markupsafe",
"package_name": "markupsafe",
"installed_version": "3.0.2",
"required_version": ">=2.1.1"
},
{
"key": "werkzeug",
"package_name": "werkzeug",
"installed_version": "3.1.3",
"required_version": ">=3.1.0"
}
]
},
...
四、pipdeptree的优势
调试依赖冲突:
- 当
pip install失败或运行时出现难以理解的importerror时,pipdeptree是首选诊断工具。 - 通过正反向查询,可以快速定位是哪个包的版本要求导致了冲突,从而做出降级、升级或寻找替代包的决策。
优化requirements.txt:
- 一个常见的反模式是将
pip freeze > requirements.txt的结果直接用于生产环境,这会将所有底层依赖(包括它们的精确版本)都冻结,导致文件冗长且难以维护。 - 而我们需要的是:
- 仅保留那些你显式安装的顶层包在
requirements.txt中。 - 使用
pipdeptree来生成这个精简列表,确保环境的可重现性同时保持文件的清晰和可管理性。
审计与安全审查:
- 在出现安全漏洞(如cve)时,安全团队通常会给出受影响的包名和版本范围。
- 使用
pipdeptree可以迅速扫描整个环境,找到所有安装了该漏洞包的地方,并追溯是哪个顶级包引入了它,从而评估影响范围并制定优先级最高的修复策略。
理解复杂项目的依赖图谱:
- 对于大型项目或框架,其依赖树可能非常深且复杂。
pipdeptree提供了不可或缺的全局视角,帮助架构师和开发者理解项目的依赖组成,避免引入不必要的或可能造成冲突的新依赖。
五、结论
pipdeptree 虽然不会每天用到,但它也是工具包中必不可少的简单且有威力的伙伴啦。
以上为个人经验,希望能给大家一个参考,也希望大家多多支持代码网。
发表评论