版本

除了在 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"])）。对于非标准版本，没有明确的排序，客户端需要决定什么规则适合他们的需求。要求服务器提供最新版本值会剥夺客户端的选择权。

具有明确“最新”版本概念的服务器（无法从客户端可用的数据中计算出来）可以提供一个非标准的下划线前缀键，如果他们希望将该信息传达给客户端。