monorepo是大型互联网公司应对高协同成本的现实选择：百人团队日均千次跨模块提交下，multirepo版本同步呈指数级增长，而monorepo通过原子提交、全局依赖收敛与完整拓扑ci保障确定性。
Monorepo 对大型互联网公司管理 Python 包不是“更倾向”，而是现实约束下的权衡选择——当团队规模超百人、日均跨模块提交超千次、依赖链深度常达 4–6 层时，multirepo 的版本同步成本会指数级上升，而 Monorepo 提供的是可落地的确定性。
跨包修改必须原子提交，否则 CI 会挂
在 multirepo 中改一个 shared-utils 的函数签名，就得：发新版本 → 等所有下游仓库 pip install → 检查是否 break → 手动修 CI。实际中常出现某服务卡在旧版，另一服务已升新版，中间协议不兼容，测试全绿但线上 500。
Monorepo 下只需一次 git commit，所有引用该函数的子包（如 api-server、data-processor）自动同步更新。CI 跑的是完整拓扑快照，不会漏掉“半升级”状态。
- 关键点：
pyproject.toml中启用[tool.poetry.workspace]，让poetry install自动识别所有packages/*子目录为本地可编辑依赖 - 陷阱：若子包用了
setuptools-scm自动生成版本号，需禁用或统一配置，否则poetry build会把每个子包当成独立发布单元，破坏原子性 - 验证方式：改
packages/core-lib/src/core_lib/__init__.py，然后poetry run pytest packages/api-server/—— 应直接生效，无需pip install -e手动链接
依赖冲突在根目录就能 resolve，不用翻 17 个 requirements.txt
大型 Python 项目常见现象：A 服务要求 requests==2.28.0（因某旧 SDK），B 服务要求 requests>=2.31.0（因安全补丁），C 服务同时依赖 A 和 B —— pip install -r requirements.txt 直接报错。
Monorepo 把所有依赖收敛到根 pyproject.toml，用 poetry lock 或 hatch env update 一次性解出全局兼容版本。失败时提示明确：“requests 无法满足 A 和 B 的约束”，而不是让开发者去猜哪个子仓的 constraints.txt 写错了。
- 注意：
poetry默认不支持子包间不同 Python 版本（如packages/legacy-job要 Py3.8，packages/new-api要 Py3.11），需拆成多个 workspace 或改用hatch - 别碰
pip-tools+requirements.in组合：它本质是multirepo思维，在Monorepo里会放大锁文件碎片化 - 真实坑：某些团队把
dev-dependencies放进根配置，结果packages/cli-tool的测试跑得慢，因为加载了packages/ml-model的 GPU 依赖
git blame 和 git log -p 能追溯完整变更链
当线上出现数据解析错误，multirepo 下要：git log 查 data-parser 仓库 → 发现某 PR 引入 bug → 进 ingestion-service 仓库查谁调用了它 → 再进 schema-registry 查 schema 是否变更 → 最后发现是 schema 版本没对齐。
Monorepo 中一条 git log -p -- packages/data-parser/ packages/ingestion-service/ packages/schema-registry/ 就能拉出全部关联变更，且 commit message 通常包含 “fix parsing regression after schema v3.2 upgrade” 这类跨域上下文。
- 前提：团队约定 commit scope 前缀，如
data-parser: fix json decode for null array，否则git log仍是噪音 - 代价：单次
git clone体积大，需配git sparse-checkout或partial clone，否则新人拉代码半小时起步 - 别指望
git bisect自动定位：Python 包之间无编译期强依赖，bisect 到某个 commit 可能只改了 docstring，真问题在上游未提交的本地修改里
真正卡住落地的从来不是工具链，而是人——当一个 PR 同时 touch 5 个子包时，Code Reviewer 很难确认 packages/auth 的改动是否无意影响了 packages/billing 的 token 校验逻辑。这需要配套的自动化契约测试（如 pytest --contract）、严格的 pre-commit 钩子（禁止跨包循环导入）、以及明确的 owner 制（每个 packages/* 目录下放 OWNERS 文件）。否则 Monorepo 不是提效，而是把问题从“版本不一致”转移到“权限失控”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
