Python单体仓库多项目依赖管理方案及对应标准规范问询

1. 全仓库统一依赖清单的合理性判断 #

不存在绝对的合理/不合理，完全取决于两个项目的耦合度和运维需求：

• 若两个项目完全独立、部署周期不同、运维团队不同、未来无公共代码抽离计划：统一依赖不合理，优先选择隔离依赖方案，你提到的冲突规避、降低回归风险的优势会远大于版本差异带来的技术债务影响
• 若两个项目属于同一业务线的配套组件、运维团队统一、有公共工具脚本/代码复用需求：可以考虑半统一方案，不需要完全共用lock文件，仅约束共享依赖的版本范围，平衡两类方案的优势

2. 相关规范说明 #

Python官方PEP没有对monorepo场景的依赖管理做强制规定，但有两个相关通用规范可参考：

• PEP 621（项目元数据规范）、PEP 631（依赖声明规范）明确要求每个可独立发布的Python项目，需要将自身的依赖声明和项目代码绑定存储，不推荐依赖项目外的全局依赖配置
• 目前业界广泛使用的Python包管理工具（Poetry、Pipenv、PDM等）的官方最佳实践，均推荐每个独立项目维护自己的依赖声明文件和lock文件，从工具设计层面默认支持隔离依赖的方案

统一依赖的额外优劣势补充 #

• 额外优势：CI流程可复用全局依赖缓存，大幅降低多项目并行构建的耗时；团队内部开发环境统一成本更低，无需为不同项目切换或安装多套依赖
• 额外劣势：只要有一个项目的依赖出现解析冲突，整个仓库的依赖都无法更新，阻塞其他项目的正常迭代；若两个项目需要支持的Python版本不同，统一依赖方案完全无法落地

隔离依赖的技术债务规避方案 #

你提到的共享依赖版本不一致的问题，可通过根目录增加constraints.txt约束文件的方案解决：将所有共享依赖的允许版本范围写在该文件中，每个项目安装依赖时加上--constraint ../constraints.txt参数，即可保证所有项目的共享依赖版本不会出现过大差异，同时不会影响各项目专属依赖的独立性

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