Python Poetry是否使用非标准pyproject.toml？非标准实现求证

关于你提到的"避免在新项目中使用Poetry，因其对关键功能采用非标准实现"的观点，需要结合Poetry的版本迭代来看——该观点在早期Poetry版本中更具参考性，但当前Poetry已大幅向Python生态标准靠拢，不过仍存在部分非标准细节：

一、pyproject.toml相关的非标准实现 #

• 自定义元数据区块：早期Poetry依赖[tool.poetry]区块管理项目元数据（名称、版本、依赖等），而PEP 621定义了标准的[project]区块来统一这类配置。虽然现在Poetry已支持PEP 621标准，但默认创建的项目仍会保留[tool.poetry]，且部分高级功能（如精细化的依赖组管理）仍依赖自定义字段，可能与仅支持PEP 621的工具（如flit）存在兼容问题。
• 自定义锁文件格式：Poetry生成的poetry.lock锁文件采用自有的格式，与pip-tools生成的锁文件不兼容。不过锁文件本身并无统一标准，这属于工具间的差异化实现，主要影响多工具混用的场景。

二、依赖管理的非标准行为 #

• 依赖解析逻辑：Poetry的依赖解析逻辑比pip更严格，部分pip可正常安装的依赖组合，Poetry会因版本冲突判定无法安装，这源于两者对依赖约束的处理方式不同。
• 虚拟环境与命令流程：Poetry默认的虚拟环境管理逻辑独立于标准venv工具，其add/remove命令会自动同步pyproject.toml与锁文件，和pip手动编辑依赖文件再生成锁的流程差异明显。

三、当前的兼容性改善 #

近年来Poetry一直在推进标准化兼容：

• 支持通过poetry export命令导出符合pip规范的requirements.txt文件，实现与pip生态的对接；
• 全面支持PEP 621的[project]元数据标准，可按需切换配置方式；
• 修复了大量第三方工具的兼容性问题，现在与pre-commit、pytest等主流工具的配合已无明显障碍。

总的来说，若团队以Poetry为核心构建工具链，兼容性问题几乎可以忽略；若需与大量仅遵循PEP标准的工具深度混用，则需要提前评估适配成本。

内容的提问来源于stack exchange，提问作者Eleanor Holley