主要观点：作者一直在抱怨 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 后端推荐。