单体仓库中如何将本地Python包安装到Docker服务并适配gcloud构建

当前配置评估 #

你目前使用本地绝对路径引用依赖的方式不符合最佳实践，该路径仅存在于你的个人开发设备，CI构建机、其他协作者的环境均无法访问，必然会导致构建失败。

可选落地方案 #

• Docker构建上下文复制方案（最适合monorepo内部依赖场景）
  你担心的「不规范」问题可以通过配置优化解决，没有本质缺陷：
  1. 调整Cloud Build的触发配置，将构建根目录设置为monorepo的根路径，而非serviceA单独目录，保证构建机可以读取到同仓库下的packageA代码
  2. 修改serviceA的Dockerfile，依赖安装前先复制packageA到镜像内固定路径：

  # 构建上下文为monorepo根目录时执行以下操作
  COPY ./packageA /tmp/packageA
  COPY ./serviceA/requirements.txt /tmp/requirements.txt
  RUN pip install -r /tmp/requirements.txt
  

  3. 将requirements.txt中的包引用路径修改为/tmp/packageA即可。版本管理可以通过给packageA配置pyproject.toml/setup.py明确版本号，每次迭代更新版本号即可，也可在依赖中指定版本避免错装。
• 私有包仓库托管方案（适合跨项目共享的公共包场景）
  除了推送到GitHub仓库引用，更推荐适配GCP生态推送到Google Artifact Registry的Python私有仓库：
  1. 给packageA配置自动发布流程，每次迭代后将版本推送到私有包仓库
  2. requirements.txt中直接写包名+版本号即可，Cloud Build默认持有当前GCP项目的Artifact Registry访问权限，不需要额外配置跨平台权限。
• monorepo专用依赖管理工具方案（适合长期维护的大型monorepo）
  可以接入Poetry、Pants这类原生支持monorepo的Python依赖管理工具，自动处理本地依赖的路径映射、版本锁定，构建时工具会自动打包关联的本地依赖到镜像中，不需要手动处理路径问题。

方案选择建议 #

如果packageA仅在当前monorepo内部的服务使用，优先选第一种方案，成本最低也符合monorepo的协作逻辑；如果packageA需要对外提供给其他项目使用，选第二种方案更合适。

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