Hatch项目中的PKG-INFO持久化元数据机制解析

在Python打包生态中，Hatch项目的hatchling构建后端近期引入了一项重要变更：当从源码分发版(sdist)构建wheel时，默认会优先使用PKG-INFO文件中的元数据而非pyproject.toml中的配置。这一改动引发了关于构建行为可预测性的深入讨论。

技术背景

传统Python打包流程中，pyproject.toml被视为项目配置的权威来源。然而随着PEP 643的推进，源码分发版中的PKG-INFO文件被赋予了新的角色——作为静态元数据的可靠来源。这种设计旨在：

1. 允许解析器直接从sdist获取元数据，避免完整的构建过程
2. 确保元数据在分发过程中的一致性

实际影响分析

在Fedora等Linux发行版的打包场景中，维护者通常会：

1. 下载PyPI上的sdist
2. 解压后修改项目文件(如依赖声明)
3. 通过PEP 517接口构建wheel

新机制导致这些修改可能被忽略，因为：

• 构建过程会优先读取PKG-INFO中的原始元数据
• 对pyproject.toml的修改不会自动同步到PKG-INFO

技术争议焦点

1. 规范符合性：PKG-INFO作为静态元数据载体，其内容应与wheel中的元数据保持一致。但这是否意味着构建后端必须依赖它？

2. 用户预期：开发者普遍认为修改pyproject.toml应该影响构建结果，新机制打破了这种心智模型。

3. 下游打包场景：发行版维护者需要修改元数据以满足系统集成需求，新机制增加了工作复杂度。

解决方案探讨

对于需要修改元数据的场景，目前可行的方案包括：

1. 直接修改PKG-INFO：保持与静态元数据规范的一致性
2. 删除PKG-INFO文件：强制后端重新生成元数据
3. 构建时标志覆盖：Hatch考虑提供忽略PKG-INFO的配置选项

技术启示

这一变更反映了Python打包生态的演进方向：

• 强化元数据的静态保证，提升工具链可靠性
• 在灵活性和确定性之间寻求平衡
• 凸显了构建产物(sdist)与开发源码的语义差异

对于高级用户，理解这一机制有助于：

• 正确处理元数据修改场景
• 设计更健壮的打包流程
• 预见未来工具链的行为变化