Following system colour scheme - Python 增强提案 Selected dark colour scheme - Python 增强提案 Selected light colour scheme - Python 增强提案

Python 增强提案

PEP 629 – PyPI 简单 API 版本控制

作者:
Donald Stufft <donald at stufft.io>
BDFL 代表:
Brett Cannon <brett at python.org>
讨论列表:
Discourse 帖子
状态:
最终
类型:
标准轨迹
主题:
打包
创建:
2020-07-16
修订历史:
2020-07-16

目录

注意

此 PEP 于 2020-08-20 被接受。PyPI 于 2020-01-28 合并了一个实现,将此 PEP 标记为“最终”。

摘要

此 PEP 提出添加一种简单 API 版本控制方法,以便客户端可以确定特定存储库支持的简单 API 功能。

理由

在改进简单 API 时,客户端希望能够确定存储库支持哪些功能。目前没有机制可以做到这一点,除非尝试通过查看响应中的数据来检测新功能,并查看是否似乎正在使用特定功能。

对于现代版本的客户端来说,这在确定存储库是否支持其想要实现的所有功能方面效果相当好,但是它没有做任何事情来告诉客户端的旧版本存储库支持它可能不理解的功能,并允许消息传递表明它可能无法正确理解存储库的输出。

一个发生这种情况的场景示例是 python-requires 元数据的逐步引入,虽然现有客户端仍然可以成功使用存储库,但他们缺乏理解此新数据的能力,而这将影响他们的行为以选择更适合最终用户的文件。

概述

此 PEP 提出在每个对简单 API 页面成功请求的响应中包含一个元标记,该标记包含一个名为“pypi:repository-version”的属性,以及一个内容,该内容是 PEP 440 兼容的版本号,并且进一步限制为仅为主版本.次版本,而不是 PEP 440 支持的其他功能。

最终将如下所示

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

在解释存储库版本时

  • 增加主版本用于表示不兼容的更改,因此不再期望现有客户端能够有意义地使用 API。
  • 增加次版本用于表示兼容的更改,因此仍然期望现有客户端能够有意义地使用 API。

任何未来的 PEP 都有权自行决定什么具体构成不兼容与兼容的更改,超出了现有客户端将能够“有意义地”继续使用 API 的广泛建议,并且可以包括添加、修改或删除现有功能。

此 PEP 预计主版本永远不会增加,并且任何未来的主要 API 演变都将使用不同的 API 演变机制。但是,主版本包含在内是为了与未来版本区分开来(例如,假设一个位于 /v2/ 的简单 api v2,但如果存储库版本设置为大于或等于 2 的版本,则会令人困惑)。

此 PEP 将当前 API 版本设置为“1.0”,并期望未来进一步改进简单 API 的 PEP 将增加次版本号。

客户端

与简单 API 交互的客户端**应该**检查每个响应的存储库版本,如果该数据不存在,**必须**假设它是版本 1.0。

遇到大于预期的主版本时,客户端**必须**以适合用户的错误消息硬性失败。

遇到大于预期的次版本时,客户端**应该**向用户发出适当的消息。

客户端**可以**继续使用功能检测来确定存储库使用哪些功能。

被否决的想法

使用头部

而不是将此信息嵌入到实际的 HTML 中,另一种方法是使用 HTTP 头。这个想法被考虑过,但最终被拒绝,因为它会使镜像不得不开始修改头,而不是能够作为文件的“哑”HTTP 服务器运行。

使用 URL

另一种传统的 API 版本控制机制是将其嵌入到 URL 中,例如 /1.0/simple/ 等等。这对于主版本更改(其中不期望旧版客户端能够继续使用它)非常有效,但它不适合次版本更新,尤其是在版本号可以被视为最终用户的咨询性信息时。


来源:https://github.com/python/peps/blob/main/peps/pep-0629.rst

上次修改:2023-09-09 17:39:29 GMT