版本

除了 PEP 691 中定义的 name、files 和 meta 键之外，顶层必须存在一个附加键 versions。此键必须包含一个版本字符串列表，指定为此项目上传的所有项目版本。该值在逻辑上是一个集合，因此不能包含重复项，并且值的顺序不重要。

files 键中列出的所有文件都必须与 versions 键中的某个版本相关联。versions 键可以包含没有相关文件的版本（如果服务器有此类概念，则表示没有文件上传的版本）。

请注意，由于服务器可能保留在采用 PEP 440 之前形成的“遗留”数据，目前不能要求版本字符串是有效的 PEP 440 版本，因此不能假定可以使用 PEP 440 规则进行排序。但是，服务器应尽可能使用规范化的 PEP 440 版本。

附加文件信息

在 files 键中添加了两个新键。

• size：此字段是强制性的。它必须包含一个整数，表示文件大小（以字节为单位）。
• upload-time：此字段是可选的。如果存在，它必须包含一个有效的 ISO 8601 日期/时间字符串，格式为 yyyy-mm-ddThh:mm:ss.ffffffZ，表示文件上传到索引的时间。如 Z 后缀所示，上传时间必须使用 UTC 时区。时间戳的小数秒部分（.ffffff 部分）是可选的，如果存在，最多可以包含 6 位精度数字。如果服务器不记录文件的上传时间信息，则可以省略 upload-time 键。

为什么不也将此数据添加到 HTML API？

可以将数据添加到 HTML API，但绝大多数消费者目前可能都是从 PyPI JSON API 获取此数据，因此已经期望解析 JSON。HTML API 的传统消费者以前从未需要此数据。

这是否意味着 HTML API 已过时？

不。PEP 691 的常见问题解答明确指出 HTML API 并未被弃用，本 PEP 并未改变这一立场。但是，希望访问本 PEP 引入的新数据的客户端将需要使用 JSON API 获取它。希望提供它的索引将需要提供 JSON 格式。

简单 API 是否正在取代 Warehouse JSON 和 XML-RPC API？

在可能的情况下，客户端应优先使用简单 API 而非 JSON 或 XML-RPC API，因为前者是标准化的，可以假定可从任何索引获取，而后者是 Warehouse 项目独有的。

然而，尽管本 PEP 使简单 API 更接近于能够取代 JSON API，但没有正式的政策规定简单 API 将复制现有 Warehouse API 涵盖的所有功能。对简单 API 的拟议添加仍将根据其各自的优点进行考虑，并且 API 应该简单且快速地用于定位项目文件的主要用例仍将是首要考虑因素。

为什么不允许其他日期格式？

ISO 8601 标准很复杂，要求客户端处理它似乎没什么价值。标准库 datetime 模块提供了解析 ISO 8601 字符串的方法，但用户可能希望在不使用 Python 的情况下访问索引数据（例如，将 curl 的输出通过管道传输到 jq）。拥有一个单一、明确定义的格式使其更容易，并且没有任何显著的缺点。

如果文件大小对于 JSON 数字来说太大怎么办？

JSON 标准没有指定如何解释数字。Python 可以在 JSON 文件中读写任意长度的整数，因此对于用 Python 编写的代码来说这不应该是一个问题。非 Python 实现可能需要注意正确处理大整数，但这预计不会成为一个显著问题。

为什么不要求 PEP 440 版本？

在编写本 PEP 时，PyPI 仍然包含（并提供）带有“遗留”版本的项目和文件。要求 PEP 440 版本将使 PyPI 无法在遵循此规范的同时提供现有内容。

理想情况下，在未来的某个时候，简单索引 API 将更新以要求 PEP 440 版本，届时本规范也应进行更新以反映这一点。然而，这一更改将需要与包括 PyPI 在内的现有索引提供者协调，以取消支持和删除不符合要求的项目和/或文件。

为什么不提供“最新版本”值？

对于 PEP 440 版本，客户端很容易做到这一点（使用 packaging 库，latest = max(Version(s) for s in proj["versions"])）。对于非标准版本，没有明确的排序，客户端需要根据自己的需求决定合适的规则。要求服务器提供最新版本值将选择权从客户端手中夺走。

如果服务器有一个明确的“最新”版本概念，并且无法从客户端可用的数据中计算出来，它们可以提供一个非标准、带下划线前缀的键来向客户端传达该信息。