Simple 仓库 API¶

Simple repository API

中文

查询可用包版本和从索引服务器检索包的界面有两种形式：HTML 和 JSON。

英文

The interface for querying available package versions and retrieving packages from an index server comes in two forms: HTML and JSON.

基本 HTML API¶

Base HTML API

中文

一个实现 Simple API 的仓库通过其基本 URL 定义，这个 URL 是所有附加 URL 所在的顶层 URL。这个 API 被称为 "simple" 仓库，因为 PyPI 的基本 URL 是 https://pypi.org/simple/。

备注

本文档中后续出现的所有 URL 都将相对于这个基本 URL（因此给定 PyPI 的 URL，/foo/ 的 URL 将是 https://pypi.org/simple/foo/）。

在仓库中，根 URL（本规范中的 / 代表基本 URL）必须是一个有效的 HTML5 页面，每个项目都应有一个单独的锚点元素。锚点的文本必须是项目的名称，href 属性必须链接到该项目的 URL。示例如下:

<!DOCTYPE html>
<html>
  <body>
    <a href="/frob/">frob</a>
    <a href="/spamspamspam/">spamspamspam</a>
  </body>
</html>

在根 URL 之下，每个仓库中的单独项目将有一个对应的 URL。该 URL 的格式为 /<project>/，其中 <project> 替换为该项目的规范化名称，因此一个名为 "HolyGrail" 的项目将有一个类似 /holygrail/ 的 URL。该 URL 必须返回一个有效的 HTML5 页面，每个文件都有一个单独的锚点元素。锚点的 href 属性必须是指向该文件下载位置的 URL，并且锚点文本必须与该 URL 的最后一个路径组件（即文件名）匹配。该 URL 应该包括一个哈希，格式为 URL 片段，语法为：#<hashname>=<hashvalue>，其中 <hashname> 是哈希函数的名称（如 sha256），<hashvalue> 是十六进制编码的摘要。

除了上述要求外，API 还具有以下约束：

所有返回 HTML5 页面的 URL 必须以 / 结尾，并且仓库应该将没有 / 结尾的 URL 重定向到带 / 的 URL。
URL 可以是绝对 URL 或相对 URL，只要它们指向正确的位置。
对文件必须托管在仓库相对位置的地方没有任何约束。
API 页面可以有其他 HTML 元素，只要包含所需的锚点元素。
仓库可以将未规范化的 URL 重定向到规范化的 URL（例如，/Foobar/ 可以重定向到 /foobar/），然而客户端不得依赖此重定向，必须请求规范化的 URL。
仓库应该选择一个哈希函数，该哈希函数在 Python 标准库的 hashlib 模块中可以保证可用（目前为 md5、sha1、sha224、sha256、sha384、sha512）。当前推荐使用 sha256。
如果某个分发文件有 GPG 签名，必须将其与该文件一起存放，文件名相同，但附加 .asc 后缀。因此，如果文件 /packages/HolyGrail-1.0.tar.gz 存在并且有关联的签名，则签名应位于 /packages/HolyGrail-1.0.tar.gz.asc。
仓库可以在文件链接上包括 data-gpg-sig 属性，值为 true 或 false，以指示是否存在 GPG 签名。做此操作的仓库应该在每个链接上都包括此属性。
仓库可以在文件链接上包括 data-requires-python 属性。这将公开相应发布的 Requires-Python 元数据字段。若该属性存在，安装工具应该在安装时忽略不满足要求的 Python 版本。例如:
```
<a href="..." data-requires-python="&gt;=3">...</a>
```
在属性值中，< 和 > 必须分别 HTML 编码为 < 和 >。

英文

A repository that implements the simple API is defined by its base URL, this is the top level URL that all additional URLs are below. The API is named the "simple" repository due to the fact that PyPI's base URL is https://pypi.org/simple/.

备注

All subsequent URLs in this document will be relative to this base URL (so given PyPI's URL, a URL of /foo/ would be https://pypi.org/simple/foo/.

Within a repository, the root URL (/ for this spec which represents the base URL) MUST be a valid HTML5 page with a single anchor element per project in the repository. The text of the anchor tag MUST be the name of the project and the href attribute MUST link to the URL for that particular project. As an example:

<!DOCTYPE html>
<html>
  <body>
    <a href="/frob/">frob</a>
    <a href="/spamspamspam/">spamspamspam</a>
  </body>
</html>

Below the root URL is another URL for each individual project contained within a repository. The format of this URL is /<project>/ where the <project> is replaced by the normalized name for that project, so a project named "HolyGrail" would have a URL like /holygrail/. This URL must respond with a valid HTML5 page with a single anchor element per file for the project. The href attribute MUST be a URL that links to the location of the file for download, and the text of the anchor tag MUST match the final path component (the filename) of the URL. The URL SHOULD include a hash in the form of a URL fragment with the following syntax: #<hashname>=<hashvalue>, where <hashname> is the lowercase name of the hash function (such as sha256) and <hashvalue> is the hex encoded digest.

In addition to the above, the following constraints are placed on the API:

All URLs which respond with an HTML5 page MUST end with a / and the repository SHOULD redirect the URLs without a / to add a / to the end.
URLs may be either absolute or relative as long as they point to the correct location.
There are no constraints on where the files must be hosted relative to the repository.
There may be any other HTML elements on the API pages as long as the required anchor elements exist.
Repositories MAY redirect unnormalized URLs to the canonical normalized URL (e.g. /Foobar/ may redirect to /foobar/), however clients MUST NOT rely on this redirection and MUST request the normalized URL.
Repositories SHOULD choose a hash function from one of the ones guaranteed to be available via the hashlib module in the Python standard library (currently md5, sha1, sha224, sha256, sha384, sha512). The current recommendation is to use sha256.
If there is a GPG signature for a particular distribution file it MUST live alongside that file with the same name with a .asc appended to it. So if the file /packages/HolyGrail-1.0.tar.gz existed and had an associated signature, the signature would be located at /packages/HolyGrail-1.0.tar.gz.asc.
A repository MAY include a data-gpg-sig attribute on a file link with a value of either true or false to indicate whether or not there is a GPG signature. Repositories that do this SHOULD include it on every link.
A repository MAY include a data-requires-python attribute on a file link. This exposes the Requires-Python metadata field for the corresponding release. Where this is present, installer tools SHOULD ignore the download when installing to a Python version that doesn't satisfy the requirement. For example:
```
<a href="..." data-requires-python="&gt;=3">...</a>
```
In the attribute value, < and > have to be HTML encoded as < and >, respectively.

规范化名称¶

Normalized Names

中文

本规范引用了“规范化”项目名称的概念。根据名称规范化规范，名称中唯一有效的字符是 ASCII 字母、ASCII 数字、.、- 和 _。名称应该小写，并且所有连续的 .、- 或 _ 字符应替换为单个 - 字符。这可以通过 Python 中的 re 模块实现:

import re

def normalize(name):
    return re.sub(r"[-_.]+", "-", name).lower()

英文

This spec references the concept of a "normalized" project name. As per the name normalization specification the only valid characters in a name are the ASCII alphabet, ASCII numbers, ., -, and _. The name should be lowercased with all runs of the characters ., -, or _ replaced with a single - character. This can be implemented in Python with the re module:

import re

def normalize(name):
    return re.sub(r"[-_.]+", "-", name).lower()

向 Simple API 添加“Yank”支持¶

Adding "Yank" Support to the Simple API

中文

简单仓库中的链接 MAY 包含一个 data-yanked 属性，该属性可以没有值，也可以有一个任意的字符串值。存在 data-yanked 属性时， SHOULD 解释为指示该链接指向的文件已被“撤回”（"Yanked"），并且通常不应被安装程序选择，除非在特定情况下。

如果存在， data-yanked 属性的值是一个任意字符串，表示文件被撤回的原因。处理简单仓库 API 的工具 MAY 将此字符串展示给最终用户。

一旦设置，撤回属性不是不可变的，未来可以被撤销（并且一旦撤销，也可以被重新设置）。因此，API 用户 MUST 能够处理被撤回的文件被“恢复” （甚至再次被撤回）的情况。

英文

Links in the simple repository MAY have a data-yanked attribute which may have no value, or may have an arbitrary string as a value. The presence of a data-yanked attribute SHOULD be interpreted as indicating that the file pointed to by this particular link has been "Yanked", and should not generally be selected by an installer, except under specific scenarios.

The value of the data-yanked attribute, if present, is an arbitrary string that represents the reason for why the file has been yanked. Tools that process the simple repository API MAY surface this string to end users.

The yanked attribute is not immutable once set, and may be rescinded in the future (and once rescinded, may be reset as well). Thus API users MUST be able to cope with a yanked file being "unyanked" (and even yanked again).

安装程序¶

Installers

中文

理想的用户体验是，一旦文件被撤回，当用户试图直接安装一个已被撤回的文件时，安装应当失败，就像该文件已被删除一样。然而，当用户在一段时间前进行此操作，而现在计算机只是继续机械地按照原始顺序安装现已被撤回的文件时，安装应当表现得就像文件没有被撤回一样。

如果选择约束可以通过非撤回版本来满足，安装程序 MUST 忽略撤回的版本；如果这意味着无法完全满足请求，安装程序 MAY 拒绝使用撤回的版本。实现 SHOULD 选择遵循上述意图精神的策略，避免对撤回版本/文件的“新”依赖。

这意味着的具体做法留给具体的安装程序决定，如何最好地融入其安装程序的整体使用。然而，有两种建议的方法：

撤回的文件始终被忽略，除非它是唯一符合精确版本指定符的文件，该版本指定符使用 == （没有任何使其成为范围的修饰符，例如 .* ）或 ===。匹配该版本指定符应按版本指定符规范进行，考虑到本地版本、零填充等情况。
撤回的文件始终被忽略，除非它是唯一符合锁定文件（如 Pipfile.lock 或 poetry.lock）中指定要安装的文件。在这种情况下，从某个输入文件或命令创建或更新锁定文件时，SHOULD 不使用撤回的文件。

无论安装程序选择何种策略来决定何时安装撤回文件，安装程序 SHOULD 在决定安装撤回文件时发出警告。该警告 MAY 利用 data-yanked 属性的值（如果有值）来向用户提供更具体的反馈，解释该文件为何被撤回。

英文

The desirable experience for users is that once a file is yanked, when a human being is currently trying to directly install a yanked file, that it fails as if that file had been deleted. However, when a human did that awhile ago, and now a computer is just continuing to mechanically follow the original order to install the now yanked file, then it acts as if it had not been yanked.

An installer MUST ignore yanked releases, if the selection constraints can be satisfied with a non-yanked version, and MAY refuse to use a yanked release even if it means that the request cannot be satisfied at all. An implementation SHOULD choose a policy that follows the spirit of the intention above, and that prevents "new" dependencies on yanked releases/files.

What this means is left up to the specific installer, to decide how to best fit into the overall usage of their installer. However, there are two suggested approaches to take:

Yanked files are always ignored, unless they are the only file that

matches a version specifier that "pins" to an exact version using either == (without any modifiers that make it a range, such as .*) or ===. Matching this version specifier should otherwise be done as per the version specifiers specification for things like local versions, zero padding, etc.

Yanked files are always ignored, unless they are the only file that

matches what a lock file (such as Pipfile.lock or poetry.lock) specifies to be installed. In this case, a yanked file SHOULD not be used when creating or updating a lock file from some input file or command.

Regardless of the specific strategy that an installer chooses for deciding when to install yanked files, an installer SHOULD emit a warning when it does decide to install a yanked file. That warning MAY utilize the value of the data-yanked attribute (if it has a value) to provide more specific feedback to the user about why that file had been yanked.

镜像¶

Mirrors

中文

镜像通常可以以两种方式处理撤回的文件：

它们可以选择完全从其简单仓库 API 中省略撤回的文件，只提供一个显示“活动的”、未撤回文件的仓库视图。
它们可以选择包含撤回的文件，并且还要镜像 data-yanked 属性。

镜像不得在未镜像 data-yanked 属性的情况下镜像已撤回的文件。

英文

Mirrors can generally treat yanked files one of two ways:

They may choose to omit them from their simple repository API completely,

providing a view over the repository that shows only "active", unyanked files.

They may choose to include yanked files, and additionally mirror the

data-yanked attribute as well.

Mirrors MUST NOT mirror a yanked file without also mirroring the data-yanked attribute for it.

PyPI Simple API 版本控制¶

Versioning PyPI's Simple API

中文

此规范提议在每个成功请求到简单 API 页面时的响应中包含一个 meta 标签，该标签具有名称属性 "pypi:repository-version"，其内容是一个与版本说明符规范兼容的版本号，进一步限制为仅支持 Major.Minor 版本，且不包含版本说明符规范支持的附加功能。

最终效果类似于:

<meta name="pypi:repository-version" content="1.0">

解释仓库版本时：

增加主版本号用于表示不兼容的变化，这样现有客户端将不再能够有意义地使用该 API。
增加次版本号用于表示向后兼容的变化，这样现有客户端仍然可以有意义地使用该 API。

具体什么变化构成不兼容或兼容的变化，留给未来规范的裁定，基本的建议是现有客户端将能够“有意义”地继续使用该 API，这可以包括添加、修改或删除现有功能。

本规范期望主版本号永远不会增加，任何未来的主要 API 进化将采用不同的机制来演化 API。然而，包含主版本号是为了与未来的版本区分开（例如，假设的简单 API v2 位于 /v2/，但如果仓库版本设置为 >= 2，则会造成混淆）。

本规范将当前 API 版本设置为 "1.0"，并期望未来进一步演化简单 API 的规范将增加次版本号。

英文

This spec proposes the inclusion of a meta tag on the responses of every successful request to a simple API page, which contains a name attribute of "pypi:repository-version", and a content that is a version specifiers specification compatible version number, which is further constrained to ONLY be Major.Minor, and none of the additional features supported by the version specifiers specification.

This would end up looking like:

<meta name="pypi:repository-version" content="1.0">

When interpreting the repository version:

Incrementing the major version is used to signal a backwards incompatible change such that existing clients would no longer be expected to be able to meaningfully use the API.
Incrementing the minor version is used to signal a backwards compatible change such that existing clients would still be expected to be able to meaningfully use the API.

It is left up to the discretion of any future specs as to what specifically constitutes a backwards incompatible vs compatible change beyond the broad suggestion that existing clients will be able to "meaningfully" continue to use the API, and can include adding, modifying, or removing existing features.

It is expectation of this spec that the major version will never be incremented, and any future major API evolutions would utilize a different mechanism for API evolution. However the major version is included to disambiguate with future versions (e.g. a hypothetical simple api v2 that lived at /v2/, but which would be confusing if the repository-version was set to a version >= 2).

This spec sets the current API version to "1.0", and expects that future specs that further evolve the simple API will increment the minor version number.

客户端¶

Clients

中文

与简单 API 交互的客户端 SHOULD 检查每个响应中的仓库版本，如果该数据不存在，MUST 假定版本为 1.0。

当遇到大于预期的主版本时，客户端 MUST 以适当的错误信息硬性失败，并向用户显示。

当遇到大于预期的次版本时，客户端 SHOULD 向用户发出适当的警告信息。

客户端 MAY 仍然可以继续使用特性检测来确定仓库使用的功能。

英文

Clients interacting with the simple API SHOULD introspect each response for the repository version, and if that data does not exist MUST assume that it is version 1.0.

When encountering a major version greater than expected, clients MUST hard fail with an appropriate error message for the user.

When encountering a minor version greater than expected, clients SHOULD warn users with an appropriate message.

Clients MAY still continue to use feature detection in order to determine what features a repository uses.

在 Simple Repository API 中提供分发元数据¶

Serve Distribution Metadata in the Simple Repository API

中文

在简单仓库的项目页面中，每个指向分发包的锚标签 可能(MAY) 具有一个 data-dist-info-metadata 属性。该属性的存在表示，锚标签所指示的分发包 必须(MUST) 包含一个核心元数据文件，该文件在分发包处理和/或安装时不会被修改。

如果存在 data-dist-info-metadata 属性，则仓库 必须(MUST) 将分发包的核心元数据文件与分发包一起提供，并在文件名末尾添加 .metadata。例如，服务于 /files/distribution-1.0-py3.none.any.whl 的分发包的核心元数据文件将位于 /files/distribution-1.0-py3.none.any.whl.metadata。这类似于基础 HTML API 规范中指定 GPG 签名文件的位置。

仓库 应该(SHOULD) 提供核心元数据文件的哈希值，作为 data-dist-info-metadata 属性的值，采用语法 <hashname>=<hashvalue>，其中 <hashname> 是所用哈希函数的小写名称，<hashvalue> 是十六进制编码的摘要。如果无法提供哈希，仓库 可能(MAY) 使用 true 作为该属性的值。

英文

In a simple repository's project page, each anchor tag pointing to a distribution MAY have a data-dist-info-metadata attribute. The presence of the attribute indicates the distribution represented by the anchor tag MUST contain a Core Metadata file that will not be modified when the distribution is processed and/or installed.

If a data-dist-info-metadata attribute is present, the repository MUST serve the distribution's Core Metadata file alongside the distribution with a .metadata appended to the distribution's file name. For example, the Core Metadata of a distribution served at /files/distribution-1.0-py3.none.any.whl would be located at /files/distribution-1.0-py3.none.any.whl.metadata. This is similar to how the base HTML API specification specifies the GPG signature file's location.

The repository SHOULD provide the hash of the Core Metadata file as the data-dist-info-metadata attribute's value using the syntax <hashname>=<hashvalue>, where <hashname> is the lower cased name of the hash function used, and <hashvalue> is the hex encoded digest. The repository MAY use true as the attribute's value if a hash is unavailable.

向后兼容性¶

Backwards Compatibility

中文

如果锚标签缺少 data-dist-info-metadata 属性，工具应该恢复其当前行为，即下载分发包以检查元数据。

不支持新 data-dist-info-metadata 属性的旧版工具应该忽略该属性，并保持其当前行为，即下载分发包以检查元数据。这类似于先前的 data- 属性添加期望现有工具操作的方式。

英文

If an anchor tag lacks the data-dist-info-metadata attribute, tools are expected to revert to their current behaviour of downloading the distribution to inspect the metadata.

Older tools not supporting the new data-dist-info-metadata attribute are expected to ignore the attribute and maintain their current behaviour of downloading the distribution to inspect the metadata. This is similar to how prior data- attribute additions expect existing tools to operate.

用于包索引的 Simple API 的附加字段¶

Additional Fields for the Simple API for Package Indexes

中文

本规范定义了简单存储库 API 的 1.1 版本。对于 HTML 版本的 API，与 1.0 版本没有变化。对于 JSON 版本的 API，做出了以下更改：

api-version 必须指定版本 1.1 或更高版本。
在顶级新增了一个 versions 键。
在 files 数据中，新增了两个 "文件信息" 键：size 和 upload-time。
带有前导下划线的键（在任何级别）被保留为索引服务器的私有键。未来的标准不会为任何此类键分配意义。

versions 和 size 键是必需的。upload-time 键是可选的。

英文

This specification defines version 1.1 of the simple repository API. For the HTML version of the API, there is no change from version 1.0. For the JSON version of the API, the following changes are made:

The api-version must specify version 1.1 or later.
A new versions key is added at the top level.
Two new "file information" keys, size and upload-time, are added to the files data.
Keys (at any level) with a leading underscore are reserved as private for index server use. No future standard will assign a meaning to any such key.

The versions and size keys are mandatory. The upload-time key is optional.

版本¶

Versions

中文

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

files 键中列出的所有文件必须与 versions 键中的某个版本关联。 versions 键可以包含没有关联文件的版本（用于表示没有上传文件的版本，如果服务器支持这种概念）。

请注意，由于服务器可能持有采用版本指定符规范（VSS）之前的 "遗留" 数据，因此当前不能要求版本字符串必须是有效的 VSS 版本，因此不能假设它们可以使用 VSS 规则进行排序。然而，服务器应尽可能使用规范化的 VSS 版本。

英文

An additional key, versions MUST be present at the top level, in addition to the keys name, files and meta defined in the JSON API specification. This key MUST contain a list of version strings specifying all of the project versions uploaded for this project. The value is logically a set, and as such may not contain duplicates, and the order of the values is not significant.

All of the files listed in the files key MUST be associated with one of the versions in the versions key. The versions key MAY contain versions with no associated files (to represent versions with no files uploaded, if the server has such a concept).

Note that because servers may hold "legacy" data from before the adoption of the version specifiers specification (VSS), version strings currently cannot be required to be valid VSS versions, and therefore cannot be assumed to be orderable using the VSS rules. However, servers SHOULD use normalised VSS versions where possible.

附加文件信息¶

Additional file information

中文

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

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

英文

Two new keys are added to the files key.

size: This field is mandatory. It MUST contain an integer which is the file size in bytes.
upload-time: This field is optional. If present, it MUST contain a valid ISO 8601 date/time string, in the format yyyy-mm-ddThh:mm:ss.ffffffZ, which represents the time the file was uploaded to the index. As indicated by the Z suffix, the upload time MUST use the UTC timezone. The fractional seconds part of the timestamp (the .ffffff part) is optional, and if present may contain up to 6 digits of precision. If a server does not record upload time information for a file, it MAY omit the upload-time key.

在 Simple API 中重命名 dist-info-metadata¶

Rename dist-info-metadata in the Simple API

中文

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 RFC 2119 中的描述进行解释。

英文

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"" in this document are to be interpreted as described in RFC 2119.

服务器¶

Servers

中文

当在 Simple API 的 HTML 表示中使用 API 元数据文件规范元数据时，MUST 使用属性名 data-core-metadata 输出，且支持的值保持不变。

当在 JSON API 规范的 JSON 表示中使用 API 元数据文件规范元数据时，MUST 使用键 core-metadata 输出，且支持的值保持不变。

为了支持使用先前键名的客户端，HTML 表示 MAY 也可以使用 data-dist-info-metadata 输出，如果这样做，MUST 与 data-core-metadata 的值匹配。

英文

The the API metadata file specification metadata, when used in the HTML representation of the Simple API, MUST be emitted using the attribute name data-core-metadata, with the supported values remaining the same.

The the API metadata file specification metadata, when used in the the JSON API specification JSON representation of the Simple API, MUST be emitted using the key core-metadata, with the supported values remaining the same.

To support clients that used the previous key names, the HTML representation MAY also be emitted using the data-dist-info-metadata, and if it does so it MUST match the value of data-core-metadata.

客户端¶

Clients

中文

消费 Simple API 的任何 HTML 表示的客户端 MUST 从键 data-core-metadata 中读取 API 元数据文件规范元数据，如果该键存在。如果 data-core-metadata 不存在，客户端 MAY 可选择使用遗留的 data-dist-info-metadata。

消费 Simple API JSON 表示的客户端 MUST 从键 core-metadata 中读取 API 元数据文件规范元数据，如果该键存在。如果 core-metadata 不存在，客户端 MAY 可选择使用遗留的 dist-info-metadata 键。

英文

Clients consuming any of the HTML representations of the Simple API MUST read the the API metadata file specification metadata from the key data-core-metadata if it is present. They MAY optionally use the legacy data-dist-info-metadata if it is present but data-core-metadata is not.

Clients consuming the JSON representation of the Simple API MUST read the the API metadata file specification metadata from the key core-metadata if it is present. They MAY optionally use the legacy dist-info-metadata key if it is present but core-metadata is not.

历史¶

History

中文

2015年9月：HTML 格式的初始版本，在 PEP 503 中
2016年7月：Requires-Python 元数据，更新至 PEP 503
2019年5月：“yank” 支持，在 PEP 592 中
2020年7月：API 版本控制约定和元数据，并将 HTML 格式声明为 API v1，在 PEP 629 中
2021年5月：提供独立于包的包元数据，在 PEP 658 中
2022年5月：JSON 格式的初始版本，提供客户端选择机制，并将两种格式都声明为 API v1，在 PEP 691 中
2022年10月：项目版本、文件大小和上传时间在 JSON 格式中的支持，在 PEP 700 中
2023年6月：重命名提供独立于包的包元数据的字段，在 PEP 714 中

英文

September 2015: initial form of the HTML format, in PEP 503
July 2016: Requires-Python metadata, in an update to PEP 503
May 2019: "yank" support, in PEP 592
July 2020: API versioning convention and metadata, and declaring the HTML format as API v1, in PEP 629
May 2021: providing package metadata independently from a package, in PEP 658
May 2022: initial form of the JSON format, with a mechanism for clients to choose between them, and declaring both formats as API v1, in PEP 691
October 2022: project versions and file size and upload-time in the JSON format, in PEP 700
June 2023: renaming the field which provides package metadata independently from a package, in PEP 714

Simple 仓库 API¶

基本 HTML API¶

规范化名称¶

向 Simple API 添加“Yank”支持¶

安装程序¶

镜像¶

PyPI Simple API 版本控制¶

客户端¶

在 Simple Repository API 中提供分发元数据¶

向后兼容性¶

基于 JSON 的 Python 包索引 Simple API¶

版本控制¶

JSON 序列化¶

项目列表¶

项目详细信息¶

内容类型¶

版本 + 格式选择¶

替代协商机制¶

URL 参数¶

端点配置¶

TUF 支持 - PEP 458¶

建议¶

用于包索引的 Simple API 的附加字段¶

版本¶

附加文件信息¶

在 Simple API 中重命名 dist-info-metadata¶

服务器¶

客户端¶

历史¶