hatch 默认不识别 monorepo 子包，需显式配置 workspace.members；poetry 需子包声明 include 才能安装；二者运行命令时工作目录策略不同，CI 中应显式指定 --cwd。
hatch 在 monorepo 里默认不识别子包
hatch 默认把整个仓库当做一个项目，pyproject.toml 在根目录时，它不会自动发现 packages/ 或 libs/ 下的多个 pyproject.toml。你运行 hatch build 或 hatch run，它只认根目录的配置，子包被完全忽略。
解决办法是显式启用 workspace 支持，并为每个子包声明为“可发现的项目”：
- 根目录
pyproject.toml中必须有[tool.hatch.workspace]，且至少包含members = ["packages/*", "libs/*"] - 每个子包的
pyproject.toml必须有[build-system]和[project]（不能是空壳） - 子包路径需匹配 glob 模式，比如
"packages/*"不会匹配packages/core/utils，得写成"packages/**"或分条列出
poetry 的 group + workspace 配置容易漏掉 include
poetry 1.4+ 支持 monorepo，但关键点不在 tool.poetry.group，而在子包的 [tool.poetry] 是否设置了 include —— 否则 poetry install 会跳过该包，哪怕它已在 pyproject.toml 的 workspace.members 里声明了。
典型错误现象：poetry install 成功但 import mylib 报 ModuleNotFoundError，因为 poetry 没把子包源码加进 Python path。
- 每个子包的
pyproject.toml必须含include = ["src"]（如果源码在src/下）或include = ["."]（如果模块在包根） -
tool.poetry.workspace.members只控制“哪些目录算 workspace 成员”，不控制“哪些文件参与构建或安装” - 用
poetry show --tree可验证子包是否被识别为本地依赖；若没出现，大概率是include或目录结构不匹配
hatch env run 和 poetry run 的工作目录行为不同
执行命令时，hatch env run 总是在当前 shell 所在目录下运行，而 poetry run 默认切换到对应子包的根目录（即该子包 pyproject.toml 所在位置），这直接影响相对路径读取、配置文件查找和 __file__ 解析。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
例如：你在根目录执行 hatch env run -e test pytest tests/，它就在根目录跑；但 poetry run pytest tests/ 如果是从子包 A 里触发的，pytest 就会在 A 目录下找 tests/，而不是仓库根。
- hatch 想模拟 poetry 行为？手动加
--cwd ./packages/myapp - poetry 想固定在根目录运行？改用
poetry run --directory . pytest tests/ - CI 脚本中建议显式指定
--cwd，避免因触发位置不同导致测试失败
依赖冲突时 hatch 不报 warning，poetry 会主动 resolve 并提示
当两个子包分别声明了 requests>=2.25.0 和 requests，hatch 构建时完全不检查跨包约束，直接照单全收；poetry 则在 poetry lock 阶段报 Because mypkg-a depends on requests>=2.25.0 and mypkg-b depends on requests 并尝试求交集。
这不是谁对谁错的问题，而是定位差异：hatch 更偏向“每个包独立构建”，poetry 更偏向“整个 workspace 统一依赖图”。如果你靠 CI 测出运行时 ImportError 才发现问题，那 hatch 的静默可能让你多走弯路。
- hatch 用户需额外加
pip-check或pipdeptree --warn fail做跨包依赖扫描 - poetry 用户要注意它 resolve 出的版本可能不是你预期的“最新兼容版”，得看
poetry show requests确认实际锁定版本 - monorepo 越大，越建议在 pre-commit 或 PR 检查中固化依赖一致性校验步骤
monorepo 的真正难点从来不在工具选哪个，而在于所有子包是否共享同一套路径解析逻辑、依赖解析策略和环境加载顺序——这些细节藏在 include、--cwd、members 的组合里，改一处，三处可能跟着偏移。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
