如何用Poetry正确管理多Python项目中的common_proj依赖？

当前方案的问题 #

你现在复制common_proj源码到proj1/proj2的方式，会导致两个核心问题：

• common_proj自身的依赖不会被Poetry识别，生产环境安装proj1/proj2的wheel时，会缺失这些依赖
• 版本更新麻烦，每次common_proj改动都要手动复制，容易出现代码不一致

推荐解决方案 #

1. 本地路径依赖（最简单直接）

这种方式适合单仓库内的多项目依赖，无需额外配置：

• 移除proj1/proj2的pyproject.toml中packages里的common_proj配置项
• 在proj1/proj2的[tool.poetry.dependencies]区块添加路径依赖：

  [tool.poetry.dependencies]
  python = "^3.8" # 保持你原有的Python版本约束
  common_proj = { path = "../common_proj" }
  

• 在proj1目录下执行poetry install，Poetry会自动关联common_proj，无需复制源码
• 构建wheel时直接执行poetry build，生产环境安装时，确保common_proj也能被访问到（可以提前把common_proj构建成wheel，或者在生产环境也使用路径依赖安装）

如果需要把common_proj的代码打包进proj1/proj2的wheel里（适合离线部署），可以配合poetry build的配置，但更推荐分别构建common_proj和proj1/proj2的wheel后一起部署。

2. Monorepo工作区模式（适合大规模多项目）

如果你的仓库是标准的monorepo结构，用Poetry的workspaces可以统一管理所有项目：

• 在仓库根目录创建pyproject.toml，配置工作区：

  [tool.poetry]
  name = "repo-root"
  version = "0.1.0"
  description = ""
  authors = []
  packages = []
  
  [tool.poetry.workspaces]
  members = ["proj1", "proj2", "common_proj"]
  

• 在proj1/proj2的pyproject.toml中，依赖common_proj时可以用路径依赖：

  [tool.poetry.dependencies]
  common_proj = { path = "../common_proj", develop = false }
  

  • develop = false表示非可编辑模式，构建时会处理依赖的版本锁定
• 在根目录执行poetry install即可一次性安装所有项目的依赖，单个项目构建还是执行cd proj1 && poetry build

3. 发布到私有仓库（适合跨团队共享）

如果common_proj需要被多个独立仓库使用，或者生产环境需要从仓库拉取依赖，可以把common_proj发布到私有PyPI仓库（如DevPI、Artifactory）：

• 配置Poetry使用私有仓库：

  [[tool.poetry.source]]
  name = "private-pypi"
  url = "https://your-private-repo-url/"
  secondary = true
  

• 发布common_proj：

  cd common_proj
  poetry publish --build --repository private-pypi
  

• 在proj1/proj2的pyproject.toml中添加版本依赖：

  [tool.poetry.dependencies]
  common_proj = "^1.0.0" # 替换为实际发布的版本号
  

• 执行poetry install时，Poetry会从私有仓库拉取common_proj及其依赖

核心优势 #

无论选择哪种方式，Poetry都会自动解析common_proj的pyproject.toml中的依赖，并将其纳入proj1/proj2的依赖树，确保生产环境安装时所有依赖都能被正确安装。

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