Windows生成的requirements.txt在Unix环境无法运行的解决方案咨询

快速解决CI报错方案 #

直接修改你的requirements.txt中pywin32对应的行，添加平台匹配标记：

pywin32==300; sys_platform == "win32"

添加后pip会自动识别当前运行环境，仅在Windows系统下安装该依赖，Unix环境自动跳过，不需要修改GitLab CI配置即可解决当前报错。

问题解答 #

1. 跨平台依赖列表生成方案

可以生成兼容多系统的依赖列表，你当前的操作流程基本合理，仅缺少了平台专属依赖的适配规则。

• 日常生成依赖列表时，推荐用pipreqs代替默认的pip freeze，pipreqs只会导出你业务代码中实际导入的依赖，不会把ipykernel这类本地开发工具的附属依赖纳入列表，从根源避免引入平台专属依赖的问题。
• 可以将依赖拆分为核心依赖和开发依赖两类：核心依赖为pandas、numpy等业务运行必须的包，放在requirements.txt中；开发依赖为ipykernel、代码格式化工具等仅开发环节需要的包，放在单独的requirements-dev.txt中，CI流程仅安装核心依赖即可。

2. setup.py的适配性

使用setup.py（更推荐当前主流的pyproject.toml）是更适合团队协作的规范化选择。

• 这类依赖声明文件支持直接通过环境标记指定平台专属依赖，安装时会自动适配当前运行系统，无需手动处理依赖适配逻辑。
• 支持可选依赖分组特性，可以把开发依赖、不同场景的专属依赖单独分组，安装时按需选择，灵活度远高于纯requirements.txt方案。
• 目前Python官方更推荐使用pyproject.toml替代老旧的setup.py，不需要编写Python代码即可完成依赖和项目信息声明，语法更简洁。

3. 跨操作系统的依赖维护方案

不需要单独维护两份按系统区分的依赖文件，会额外增加后续版本同步的维护成本，单份带环境标记的依赖文件完全可以满足跨平台需求。

• 仅当不同系统下的核心依赖版本约束存在无法兼容的差异时，才需要拆分不同系统的依赖文件，绝大多数业务场景用环境标记即可覆盖需求。
• 如果确实需要区分开发和生产依赖，仅需要拆分核心依赖和开发依赖两个文件即可，不需要按平台维度拆分。

内容的提问来源于stack exchange，提问作者Pascal