依赖管理：requirements.txt 和 Pipenv/Poetry

Pipenv和Poetry通过自动化虚拟环境与锁文件机制解决依赖管理问题。1. 它们自动创建隔离环境，避免全局污染；2. 使用Pipfile.lock或poetry.lock锁定所有依赖精确版本，确保构建可复现；3. 内置依赖解析器减少版本冲突；4. 支持开发与生产依赖分离，提升团队协作效率。相较于requirements.txt的手动管理，二者提供更稳定、自动化和标准化的解决方案。

Python项目中的依赖管理，简单来说，就是确保你的代码能在一个稳定、可复现的环境中运行，不会因为依赖包的版本问题而“水土不服”。传统的

requirements.txt

解决方案

依赖管理的核心在于确定项目所需的外部库及其精确版本，并确保这些库能够被正确安装和使用。

requirements.txt

requirements.txt

pip freeze > requirements.txt

pip install -r requirements.txt

然而，它的局限性也很明显：

1. 缺乏环境隔离：

   requirements.txt

   登录后复制
   本身不创建虚拟环境。你需要在项目根目录手动创建并激活虚拟环境（例如

   python -m venv .venv

   登录后复制
   ），然后才能安全地安装依赖。这增加了手动操作的步骤，也容易出错。
2. 非确定性安装：

   requirements.txt

   登录后复制
   默认只记录顶级依赖，不记录其子依赖（transitive dependencies）的精确版本。这意味着，如果一个顶级依赖的子依赖更新了，你的项目在不同时间或不同机器上安装时，可能会得到不同的子依赖版本，从而导致构建不一致甚至运行时错误。
3. 依赖冲突解决弱：当项目中有多个顶级依赖，它们又各自依赖同一个库的不同版本时，

   pip

   登录后复制
   很难智能地解决冲突。你可能需要手动调整版本，这非常耗时且容易出错。
4. 开发与生产依赖混淆：通常，开发时我们可能需要一些测试工具、代码格式化工具，这些在生产环境中是不需要的。

   requirements.txt

   登录后复制
   很难优雅地区分这些不同类型的依赖。

Pipenv：集成虚拟环境与确定性构建

Pipenv 的出现，就是为了解决

requirements.txt

• Pipfile

  登录后复制
  和

  Pipfile.lock

  登录后复制
  ：Pipenv 使用

  Pipfile

  登录后复制
  来声明项目所需的顶级依赖，这比

  requirements.txt

  登录后复制
  更具可读性。更关键的是，它会自动生成

  Pipfile.lock

  登录后复制
  文件。这个

  lock

  登录后复制
  文件会精确记录所有（包括子依赖）的哈希值和版本信息，确保每次安装都能得到完全相同的依赖集合，实现了确定性构建。
• 自动创建和管理虚拟环境：你不需要手动创建虚拟环境。

  pipenv install

  登录后复制
  命令会自动为你的项目创建一个隔离的虚拟环境，并将依赖安装进去。

  pipenv shell

  登录后复制
  可以激活这个环境。
• 更好的依赖冲突解决：Pipenv 在解析依赖时，会尝试找到一个兼容所有声明依赖的版本组合，减少了手动干预。

Poetry：更现代的打包与依赖管理

Poetry 是一个更全面、更现代的Python项目管理工具，它不仅仅是依赖管理器，更是一个打包工具。

• pyproject.toml

  登录后复制
  ：Poetry 遵循

  pyproject.toml

  登录后复制
  标准（PEP 518/621），将项目元数据、依赖、构建配置等都统一到一个文件中。这让项目配置更加清晰和标准化。

• poetry.lock

  登录后复制
  ：与 Pipenv 类似，Poetry 也使用

  poetry.lock

  登录后复制
  文件来锁定所有依赖的精确版本，保证了环境的可复现性。
• 集成打包与发布：Poetry 的一大亮点是其对包的构建和发布有原生支持。你可以用

  poetry build

  登录后复制
  构建你的包，用

  poetry publish

  登录后复制
  发布到 PyPI，整个流程非常顺畅。
• 依赖组（Dependency Groups）：Poetry 允许你定义不同的依赖组，比如

  dev

  登录后复制
  （开发）、

  test

  登录后复制
  （测试）等，可以按需安装，完美解决了开发与生产依赖分离的问题。

为什么传统的

requirements.txt

登录后复制

无法满足现代Python项目需求？

说实话，刚开始写Python的时候，

pip freeze > requirements.txt

一个明显的痛点就是环境隔离。如果你不手动创建虚拟环境，直接

pip install -r

requests==2.20.0

requests==2.28.0

再者，考虑一下确定性构建。

requirements.txt

requirements.txt

另外一个角度看，依赖冲突的解决在

requirements.txt

flask

Werkzeug<2.1

some-other-lib

Werkzeug>=2.2

pip

最后，开发与生产依赖的分离也是一个头疼的问题。开发时我们可能需要

pytest

black

flake8

requirements.txt

requirements_dev.txt

requirements_prod.txt

Pipenv 和 Poetry 如何解决依赖冲突和环境隔离问题？

Pipenv 和 Poetry 在解决这些问题上，思路是相似的，但实现上各有侧重。它们的核心武器就是虚拟环境的自动化管理和锁文件（lock file）机制。

虚拟环境的自动化管理： 在我看来，这是它们最直观的优势。你不需要再手动

python -m venv .venv

source .venv/bin/activate

pipenv install

poetry install

.virtualenvs

.venv

这意味着：

乾坤圈新媒体矩阵管家

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

17

查看详情

• 项目隔离：每个项目都有自己独立的依赖集合，互不干扰。项目A的

  requests

  登录后复制
  版本不会影响项目B的

  requests

  登录后复制
  版本。
• 环境干净：你的全局Python环境保持整洁，避免了“依赖地狱”。
• 操作简化：你只需要记住

  pipenv shell

  登录后复制
  或

  poetry shell

  登录后复制
  就能进入环境，或者直接用

  pipenv run <command>

  登录后复制
  /

  poetry run <command>

  登录后复制
  来执行环境内的命令。

锁文件（

Pipfile.lock

poetry.lock

Pipfile

pyproject.toml

pipenv install

poetry install

1. 解析依赖树：它们会递归地找出你所有顶级依赖及其所有子依赖，构建出一个完整的依赖图。
2. 解决冲突：在这个过程中，它们会尝试找到一个所有依赖都能兼容的版本组合。如果存在冲突，它们会尽力解决，或者给出明确的冲突提示。
3. 生成锁文件：一旦找到一个可行的依赖组合，它们就会将这个组合中所有依赖（包括顶级和子依赖）的精确版本号和哈希值记录到

   Pipfile.lock

   登录后复制
   或

   poetry.lock

   登录后复制
   文件中。

这个锁文件就是你的“依赖快照”。当你将项目提交到版本控制系统时，这个锁文件也应该被提交。这样，团队里的其他成员，或者你在另一台机器上，只需要运行

pipenv install

poetry install

这带来了巨大的好处：

• 确定性构建：无论何时何地，只要有锁文件，你的依赖环境就永远是可复现的。彻底告别了“在我机器上跑得好好的”这种尴尬。
• 减少冲突：虽然不能完全消除所有冲突（有些冲突可能根本无解），但它们在解析阶段就帮你做了大量工作，大大减少了手动解决冲突的频率。即使有冲突，锁文件也能帮助你快速定位问题。
• 团队协作效率：团队成员之间可以共享同一个可复现的开发环境，减少了因环境差异导致的问题和沟通成本。

总的来说，Pipenv 和 Poetry 通过自动化虚拟环境和引入强大的锁文件机制，将依赖管理从一个手动、易错的过程，提升到了一个自动化、确定性、高效率的水平。

在什么场景下，我应该选择 Pipenv 还是 Poetry？

在我个人看来，选择 Pipenv 还是 Poetry，很大程度上取决于你的项目类型、团队偏好以及你对“一体化”工具的需求程度。这两个工具都比

requirements.txt

选择 Pipenv 的场景：

• 从

  requirements.txt

  登录后复制
  迁移，寻求更平滑的过渡：如果你和你的团队习惯了

  pip

  登录后复制
  的工作流，Pipenv 会是一个非常好的起点。它的命令结构和

  pip

  登录后复制
  有些相似，学习曲线相对平缓。它专注于解决虚拟环境和依赖锁的问题，不会引入太多额外的概念。
• 简单的应用项目或脚本：对于那些不需要打包发布到 PyPI，只是内部使用或者部署到服务器的Web应用、数据分析脚本等，Pipenv 提供的功能已经足够强大。它能很好地处理依赖冲突和环境隔离，保持项目的整洁。
• 对

  pyproject.toml

  登录后复制
  尚未有强烈需求：Pipenv 使用

  Pipfile

  登录后复制
  来管理依赖，这在当时是一个创新。如果你觉得

  pyproject.toml

  登录后复制
  带来的额外配置有点多余，或者团队还没有全面拥抱它，Pipenv 是一个务实的选择。
• 偏爱更轻量级的解决方案：相较于 Poetry，Pipenv 在功能上更聚焦于依赖管理和虚拟环境，没有集成打包、发布等高级功能，所以如果你不需要这些，它会显得更“轻量”。

选择 Poetry 的场景：

• 开发需要发布到 PyPI 的库或包：这是 Poetry 最闪耀的领域。它从设计之初就考虑了包的构建、发布和元数据管理。使用

  pyproject.toml

  登录后复制
  统一配置项目信息、依赖、构建系统，然后通过

  poetry build

  登录后复制
  和

  poetry publish

  登录后复制
  一键完成发布，这个流程的顺畅度是 Pipenv 无法比拟的。我个人在开发开源库时，几乎都用 Poetry，因为它真的省去了很多配置

  setup.py

  登录后复制
  的麻烦。
• 追求现代、统一的项目配置标准：Poetry 拥抱了

  pyproject.toml

  登录后复制
  标准，这代表了 Python 项目配置的未来趋势。如果你希望你的项目配置更加标准化、可维护，并且未来可能会将其他工具（如

  black

  登录后复制
  ,

  isort

  登录后复制
  ,

  pytest

  登录后复制
  等）的配置也集成到

  pyproject.toml

  登录后复制
  中，那么 Poetry 是一个更具前瞻性的选择。
• 需要精细的依赖组管理：Poetry 的依赖组功能非常强大，可以清晰地区分开发依赖、测试依赖、文档依赖等。这对于大型项目或者有复杂开发流程的团队来说，非常有价值，可以按需安装，避免不必要的依赖膨胀。
• 喜欢更严格、更一致的开发流程：Poetry 在很多方面都提供了更严格的规范和更一致的命令行体验。它的依赖解析算法通常被认为更健壮，能更好地处理复杂的依赖图。

我的个人倾向：

我个人倾向于 Poetry，尤其是在开发需要发布到PyPI的库时，它的集成度真的很高，省去了很多配置的麻烦。对于内部使用的Web服务或微服务，如果团队已经熟悉

pyproject.toml

从

requirements.txt

登录后复制

迁移到 Pipenv 或 Poetry 有哪些常见挑战？

从

requirements.txt

一个最直接的问题就是如何导入现有的依赖。你可能已经有一个非常庞大的

requirements.txt

pipenv install -r requirements.txt

poetry add

• Pipenv：

  pipenv install -r requirements.txt

  登录后复制
  会尝试将

  requirements.txt

  登录后复制
  中的所有依赖都添加到

  Pipfile

  登录后复制
  中。如果你的

  requirements.txt

  登录后复制
  是

  pip freeze

  登录后复制
  出来的，里面包含了大量的传递性依赖，那么

  Pipfile

  登录后复制
  就会变得非常臃肿，失去了它作为“顶级依赖声明”的初衷。更好的做法是手动审查

  requirements.txt

  登录后复制
  ，只把那些你直接用到的顶级依赖添加到

  Pipfile

  登录后复制
  ，让 Pipenv 自己去解析和锁定子依赖。这需要一些人工判断和清理。
• Poetry：Poetry 也有类似的问题。

  poetry add

  登录后复制
  是逐个添加依赖的，如果你想批量导入，可能需要写脚本或者同样手动清理。一个常见的策略是，先创建一个空的

  pyproject.toml

  登录后复制
  ，然后根据

  requirements.txt

  登录后复制
  的内容，逐步添加顶级依赖。

第二个挑战是学习新的工作流程和命令。从

pip install

pip freeze

python -m venv

pipenv install

pipenv shell

pipenv run

poetry add

poetry install

poetry shell

Pipfile

Pipfile.lock

pyproject.toml

poetry.lock

pipenv run

python app.py

再来，处理现有的虚拟环境。如果你的项目之前已经有了一个

.venv

virtualenvwrapper

依赖解析的差异也可能带来惊喜。

pip

requirements.txt

lock

requirements.txt

最后，CI/CD 流程的调整也是一个不可避免的环节。你的持续集成/持续部署脚本需要从

pip install -r

pipenv install --deploy

poetry install --no-dev

这些挑战虽然存在，但一旦克服，新的依赖管理工具带来的效率提升和稳定性是显而易见的。这就像从手动挡汽车换到自动挡，一开始可能不习惯，但长远来看，驾驶体验会好很多。

以上就是依赖管理：requirements.txt 和 Pipenv/Poetry的详细内容，更多请关注php中文网其它相关文章！