当前位置：首页 > news >正文

Python打包元数据困境：约束的重要性

news 来源：原创 2025/7/12 23:47:33

在Python社区中，一项旨在建立新的通用锁文件标准的努力正在展开，这一努力主要在Python讨论论坛上进行。此倡议凸显了创建一个让所有人都满意的标准化方案的难度。不同Python打包工具对锁文件应有的形态和用途有着略微不同的理解。然而，在这些讨论中，另一个小问题也重新浮现：Python存在元数据问题。Python的元数据系统过于复杂，并且缺乏必要的约束。

一、JavaScript：有用的约束示例

JavaScript提供了一个极好的例子，说明了如何通过约束简化并改进系统。无论是在本地开发还是使用npm上的包，元数据都以相同的方式表示。每个包都有一个package.json文件，其中包含了包最重要的元数据，比如名称、版本或依赖项。这种简单性带来了显著但有益的约束：

一致性：无论何时何地，开发者都可以期待找到相同的元数据格式。
可预测性：由于结构固定，易于预测和解析元数据。
简化工具构建：对于构建工具来说，处理固定的元数据格式比处理多种多样的格式要容易得多。

二、Python：过少约束的成本

相比之下，Python历史上对元数据施加的约束非常少。例如，基于旧的setup.py构建系统实际上允许在构建过程中执行任意代码。虽然曾强烈建议该构建步骤产生的版本与上传到PyPI的版本匹配，但在实践中，如果关于版本的说法不准确也是可以接受的。你可以上传一个声称是2.0版本的源分发包，但实际上安装的是2.0+somethinghere或者是一个完全不同的版本。

三、动态元数据的问题

更严重的是，在包发布到PyPI之前以及从网上下载后本地安装时，元数据都是从头开始生成的。这不仅意味着元数据不需要匹配，还意味着它可以完全不同。对于一个包来说，它可以在你的机器上声明依赖于某个“酷”依赖项，而在我的机器上则依赖于一个“不酷”的依赖项；甚至根据一天中的时间或月相来决定依赖关系也是被允许的。

尽管新推出的pyproject.toml标准鼓励使用静态元数据，但构建系统仍然完全可以回退到所谓的“动态元数据”，而且这种情况相当常见。在实践中，这样的系统给所有人带来了一种很容易被忽视的巨大负担。

四、改变现状

针对Python中动态元数据带来的挑战，除非你正在编写解析器或打包工具，否则可能不会深刻感受到其痛点。事实上，许多人可能会享受动态元数据所带来的灵活性。因此，当有人提出移除动态元数据的想法时，往往受到强烈的反对。因为有许多工作流程似乎依赖于它。

解决这个问题现在可能非常困难，因为它更多是一个社会问题而非技术问题。如果一开始就有适当的约束，这些奇怪的用例可能永远不会出现。但由于缺乏约束，人们自由地利用它，导致了一系列后果。

敖行客认为现在值得尝试改变这一状况，但尚不清楚是否可以通过标准来实现。也许解决方案在于像uv或poetry这样的工具警告使用动态元数据的行为，并强烈劝阻这样做。随着时间推移，使用动态元数据包的用户会开始敦促包作者停止使用它。

Python的元数据系统面临着复杂性和一致性的挑战，而这些问题根源在于历史上的宽松政策。通过引入更多约束，如JavaScript生态系统所展示的那样，我们可以简化这个系统，提高可靠性和可维护性。虽然改变现有的做法可能遇到阻力，但从长远来看，这对于整个Python社区是有益的。我们应当共同努力，朝着更加规范化的方向前进，以确保Python生态系统的持续健康发展。

科技脉搏，每日跳动。

——敖行客Allthinker与您共享未来之声

- 智慧链接思想协作 -

一、JavaScript：有用的约束示例

二、Python：过少约束的成本

三、动态元数据的问题

四、改变现状

相关文章：