主要观点:作者一直在抱怨 Poetry 项目,特别是其将 poetry-core 用作构建系统,认为它像个“踩坑利器”,决定写博客总结其常见缺陷。
关键信息:
- 噩梦般的 caret 操作符:Poetry 教用 SemVer 风格固定依赖,但 caret 操作符常被滥用,导致一些依赖过紧或过松,如 tzdata = "^2023.3"存在问题。
- 误导性的 include 键:人们用 include 和 exclude 键控制源分发文件包含,但普通 include 键会同时包含在源和二进制分发中,需明确标注格式,且文档示例有误,人们常重复犯错。
- 薛定谔的可选依赖:Poetry 声明可选依赖方式特殊,需添加到依赖组才是真正可选,否则会被视为必需依赖,2020 年就有关于处理可选依赖混乱的 bug。
重要细节: - 关于 caret 操作符,举例说明其在不同版本语义下的使用及问题。
- 对于 include 键,详细解释其错误使用方式及正确做法。
- 阐述可选依赖的特殊声明方式及容易被忽略的问题。
总结:Poetry 作为构建系统存在诸多直观且易犯错的问题,其他 PEP 517 后端也有不足,但 Poetry 问题更严重,作者给出不同类型 Python 包的 PEP517 后端推荐。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。