Python Poetry 项目中解决 setup.py 依赖 torch 等自定义模块的构建问题

在 Python 生态系统中，使用 Poetry 作为依赖管理工具时，经常会遇到一个典型问题：当某些 AI/ML 相关的 Python 包（如 detectron2、mmdetection 等）在其 setup.py 文件中直接导入 torch 等第三方模块时，会导致构建失败。本文将深入分析这一问题的成因，并提供可行的解决方案。

问题现象分析

当尝试使用 Poetry 安装或锁定那些在 setup.py 中直接导入 torch 的包时，会出现 "ModuleNotFoundError: No module named 'torch'" 错误。这是因为：

1. Poetry 在解析依赖时会创建一个全新的隔离虚拟环境
2. 这个临时环境默认不继承系统已安装的包
3. setup.py 在构建阶段就需要 torch 模块，但此时尚未安装

技术背景

Poetry 的依赖解析机制采用 PEP 517 标准，这意味着它会创建一个干净的构建环境。这种设计确保了构建过程的可重复性，但也带来了以下挑战：

• 构建时依赖（setup.py 中需要的模块）必须在构建环境中可用
• 许多 AI 框架的 setup.py 会动态计算版本或编译选项，需要运行时导入 torch
• 传统的 setuptools 没有明确定义这些构建时依赖

解决方案比较

1. 官方推荐方案

最规范的解决方法是推动上游项目改进其构建配置：

• 在 pyproject.toml 中明确定义构建依赖
• 发布预编译的 wheel 包
• 避免在 setup.py 中直接导入第三方模块

2. 临时解决方案

在实际开发中，如果无法立即修改上游项目，可以考虑以下方法：

方法一：设置环境变量

export VIRTUALENV_SYSTEM_SITE_PACKAGES=true
poetry install

这个方案让 Poetry 创建的临时构建环境能够访问系统已安装的包。

方法二：使用传统安装方式

poetry export --output=requirements.txt
pip install -r requirements.txt

虽然这不是 Poetry 的原生方式，但在某些场景下可以作为过渡方案。

最佳实践建议

1. 对于项目维护者：

• 遵循 PEP 517/518 规范定义构建依赖
• 将 setup.py 中的动态导入改为静态配置
• 提供预编译的 wheel 发布包

2. 对于使用者：

• 优先选择提供规范构建配置的包版本
• 在 Docker 等隔离环境中使用时，预先安装必要的构建依赖
• 考虑提交 PR 帮助上游项目改进构建配置

总结

Python Poetry 与某些 AI 框架的构建冲突反映了 Python 打包生态系统的演进过程。理解这一问题的技术背景有助于开发者做出更合理的架构决策。虽然存在临时解决方案，但从长远来看，推动项目遵循现代 Python 打包标准才是根本解决之道。