Python封装库依赖管理 实测踩坑3步解决

就本人实际测试Python 3.9.7而言，曾遭遇requirements.txt依赖版本冲突致使线上服务出现崩溃状况的坑，对于新手来讲，只要依照步骤逐个进行操作，便能够较为轻松地躲开这类常见问题。

1 创建隔离虚拟环境

于项目根目录之处，打开终端，去执行 python -m venv venv操作以创建独立环境，而后运行venvScriptsactivate（此为Windows系统的情况），或者运行source venv/bin/activate（此为Mac/Linux系统的情况），在激活之后，命令行前缀便会出现 (venv) 这样的标识。紧接着，使用pip install –upgrade pip这一指令，将包管理工具升級至21.0及更高版本，以此防止后续的安装情况出现报错现象。

【新手避坑】

常常出现的报错是：“‘环境虚拟’并非是内部的一个命令，也不是在外部能够找到的命令”，其缘由在于系统的路径当中并没有把Python脚本所在的目录涵盖进去。存在的解决方式为：再次进行Python安装时进行勾选“把Python给添加到路径当中”，或者是手动地将C盘下的Python39文件夹里的Scripts文件夹添加到环境变量此范围之内。另外在激活之后要是仍然调用全局的pip，那就利用where pip的操作来检查路径是不是指向虚拟环境venv的内部。

2 冻结当前精确依赖列表

项目调试成功之后，于终端之中执行 pip freeze > requirements.txt。把生成的txt文件打开，将所有包版本号由 包名==版本号改作 包名==版本号 的精确样式（原本便是如此）。需重点关注的参数其最优的推荐数值为：一定要运用 == 来确定版本，就像 requests==2.26.0 这样，而不要采用 >= 或者 ^。原因在于随意地进行升级有可能会引入不兼容的 API ，进而致使生产环境突然出现故障，在锁定之后每次进行部署都能够重现同一套依赖。

【新手避坑】

通常出现的报错状况为，freeze导出了 pkg-resources==0.0.0 这个版本，或者导出的是 file:// 这种路径格式。其背后的缘由在于，系统存在全局包混用的情况，又或者是 pip 版本太过陈旧了。有这样一种解决办法，第一步是先去执行pip list ，借此检查一下是否存在有异常的包，第二步呢，要给pip升级到最新版本，具体做法是使用python -m pip install –upgrade pip ，第三步，在重新激活虚拟环境之后，再去执行freeze。

3 一键安装还原所有库

当拿到他人给予的项目或者全新的机器之后进行操作，要先去激活基于虚拟的环境，接着再遵照要求执行pip install -r requirements.txt -i https://pypi.douban.com/simple这样带有格式性质的操作事项，此为添加国内镜像加速的具体做法。在整个这样一环扣一环进行的过程当中，会依据给定原则自动地去拉取保存在相应位置的并且安装能够与之处于匹配状态的每个精确版本。若碰到某一包编译遭遇失败的情况，能够单独去执行pip install包名==版本号 –no-deps，借此跳过依赖，随后再手动进行补全喔。

【新手避坑】

报错情况为高频且呈现得完整，具体是：ERROR，即出现了错误提示，提示内容是：Could not find，也就是未能找到，一个版本，该版本能够满足，相应的要求，即：xxx这个要求，其中“from versions: none”表示从版本情况来看是没有可满足的呢。一站式解决流程：第一步，检查网络，换用清华源 -i https://pypi.tuna.tsinghua.edu.cn/simple；第二步，删除requirements.txt中该包行，单独用 pip install 包名 看哪个版本可用，再把正确版本号写回文件；第三步，若包是私有源，先执行 pip config set global.index-url 你的私有源地址。

两种依赖管理方案对比

方案A，也就是纯requirements.txt的那种，具有轻量的特点，并且没有额外的工具，它比较适合那种一次性的脚本，或者对于Docker层缓存来说是友好的。方案B，即Pipenv，它能够自动生成Pipfile.lock，而且支持开发和生产进行分组，不过呢，它首次安装的时候速度比较慢，在Windows系统下的兼容性也稍微有点差。关于取舍的逻辑是这样的：如果是单人维护的小工具，那就选择A；要是团队协作、并且需要严格锁定传递依赖的大型项目，那就选择B。

不适用场景与替代方案

此方法对C/C++扩展库（像是numpy要经编译那般）或者conda环境管理的混合语言项目并不适用。要是碰到大量二进制包编译失败的情况，建议采用conda env export -n那个环境名 > environment.yml，接着运用conda env create -f environment.yml来重建，conda能够自动处理底层系统库。

你在进行库的封装操作之际，可存有面临那样一种如同“版本地狱”状况的依赖冲突呢？倘若有的话欢迎于评论区域抛出你所遭遇的报错截图，一旦点赞数量超过100，我便会推出下一期包含《私有仓库打包避坑手册》的内容。