核心元数据规范¶

本页面描述了 2025 年 9 月批准的 2.5 版本。

以下规范中定义的字段应被视为有效、完整且不可更改。所需字段为：

Metadata-Version
Name
Version

所有其他字段均为可选。

元数据（包括 wheels 和已安装项目中的元数据）的标准文件格式基于电子邮件头格式。然而，电子邮件格式已经修订了多次，具体哪个电子邮件 RFC 适用于打包元数据并未明确规定。在没有精确定义的情况下，实际标准由标准库 email.parser 模块使用 compat32 策略解析的内容设定。

无论何时将元数据序列化为字节流（例如，保存到文件），字符串都必须使用 UTF-8 编码进行序列化。

尽管 PEP 566 定义了一种将元数据转换为 JSON 兼容字典的方法，但这尚未用作标准交换格式。工具需要处理多年来的现有包，这使得难以转换为新格式。

注意

解释旧元数据： 在 PEP 566 中，版本说明符字段格式规范被放宽以接受流行的发布工具使用的语法（即删除版本说明符必须用括号括起来的要求）。元数据消费者可能希望即使对于名义上低于 2.1 版本的元数据文件也使用更宽松的格式规则。

Metadata-Version¶

1.0 版本新增。

文件格式版本；合法值为“1.0”、“1.1”、“1.2”、“2.1”、“2.2”、“2.3”、“2.4”和“2.5”。

消费元数据的自动化工具如果 metadata_version 大于其支持的最高版本，则应发出警告，并且如果 metadata_version 的主版本大于其支持的最高版本，则必须失败（如版本说明符规范中所述，主版本是第一个点之前的值）。

为了更广泛的兼容性，构建工具可以选择使用包含所有所需字段的最低元数据版本来生成分发元数据。

示例

Metadata-Version: 2.4

Name¶

1.0 版本新增。

2.1 版本有变动：添加了名称格式的格式限制。

分发的名称。名称字段是分发的主要标识符。它必须符合名称格式规范。

示例

Name: BeagleVote

为了比较目的，名称在比较之前应进行规范化。

Version¶

1.0 版本新增。

一个包含分发版本号的字符串。此字段必须采用版本说明符规范中指定的格式。

示例

Version: 1.0a2

Dynamic (多用途)¶

2.2 版本新增。

一个包含另一个核心元数据字段名称的字符串。字段名称 Name、Version 和 Metadata-Version 不得在此字段中指定。

当在源分发的元数据中找到时，适用以下规则：

如果一个字段未标记为 Dynamic，则从 sdist 构建的任何 wheel 中该字段的值必须与 sdist 中的值匹配。如果该字段不在 sdist 中，并且未标记为 Dynamic，则它不得出现在 wheel 中。
如果一个字段标记为 Dynamic，则它在从 sdist 构建的 wheel 中可以包含任何有效值（包括完全不存在）。

如果 sdist 元数据版本早于 2.2 版本，则所有字段都应被视为已指定 Dynamic（即，从 sdist 构建的 wheel 的元数据没有特殊限制）。

在除源分发之外的任何上下文中，Dynamic 仅供参考，表示字段值是在 wheel 构建时计算的，可能与 sdist 或项目中其他 wheel 中的值不相同。

特别要注意的是，如果您获得了预构建的 wheel，您不能假设未标记为 Dynamic 的字段在其他 wheel 中会具有相同的值，因为某些 wheel 不是直接从 sdist 构建的，而是从现有 wheel 修改的（例如，auditwheel 工具就是这样做的，并且在为 PyPI 构建 wheel 时通常使用）。此类修改可能包括更改元数据（甚至是不可动态的元数据）。同样，如果您有一个 sdist 和一个您没有从该 sdist 构建的 wheel，您不能假设 wheel 的元数据与 sdist 的元数据匹配，即使该字段未标记为 Dynamic。

Dynamic 语义的完整细节在 PEP 643 中描述。

Platform (多用途)¶

1.0 版本新增。

一个平台规范，描述了分发支持的、未在“操作系统”Trove 分类器中列出的操作系统。参见下面的“Classifier”。

示例

Platform: ObscureUnix
Platform: RareDOS

Supported-Platform (多用途)¶

1.1 版本新增。

包含 PKG-INFO 文件的二进制分发将在其元数据中使用 Supported-Platform 字段来指定编译二进制分发的 OS 和 CPU。Supported-Platform 字段的语义未在此 PEP 中指定。

示例

Supported-Platform: RedHat 7.2
Supported-Platform: i386-win32-2791

Summary¶

1.0 版本新增。

分发功能的单行摘要。

示例

Summary: A module for collecting votes from beagles.

Description¶

1.0 版本新增。

2.1 版本有变动：此字段可以在消息正文中指定。

分发的较长描述，可以跨越多个段落。处理元数据的软件不应假设此字段的最大大小，尽管人们不应将其说明手册作为描述。

此字段的内容可以使用 reStructuredText 标记 [1] 编写。对于使用元数据的程序，支持标记是可选的；程序也可以按原样显示字段内容。这意味着作者在使用标记时应保守。

为了支持空行和相对于 RFC 822 格式的缩进行，任何 CRLF 字符必须后缀 7 个空格，然后是一个管道符 (“|”)。因此，Description 字段被编码为一个可由 RFC822 解析器 [2] 解释的折叠字段。

示例

Description: This project provides powerful math functions
        |For example, you can use `sum()` to sum numbers:
        |
        |Example::
        |
        |    >>> sum(1, 2)
        |    3
        |

此编码意味着当使用 RFC822 读取器展开字段时，任何出现 CRLF 后跟 7 个空格和一个管道符的序列都必须替换为单个 CRLF。

或者，分发的描述也可以在消息正文中提供（即，在标题后完全空白行之后，不需要缩进或其他特殊格式）。

Description-Content-Type¶

2.1 版本新增。

一个字符串，说明分发描述中使用的标记语法（如果有），以便工具可以智能地渲染描述。

历史上，PyPI 支持纯文本和 reStructuredText (reST) 格式的描述，并且可以将 reST 渲染为 HTML。然而，分发作者通常使用 Markdown (RFC 7763) 编写描述，因为许多代码托管网站会渲染 Markdown README，作者会重复使用该文件作为描述。PyPI 不识别该格式，因此无法正确渲染描述。这导致 PyPI 上许多包的描述在 Markdown 被保留为纯文本时渲染效果不佳，更糟糕的是，尝试将其渲染为 reST。此字段允许分发作者指定其描述的格式，从而为 PyPI 和其他工具渲染 Markdown 和其他格式提供了可能性。

此字段的格式与 HTTP 中的 Content-Type 头部相同（即：RFC 1341）。简而言之，这意味着它有一个 type/subtype 部分，然后可以选择具有多个参数。

Format

Description-Content-Type: <type>/<subtype>; charset=<charset>[; <param_name>=<param value> ...]

type/subtype 部分只有少数合法值：

text/plain
text/x-rst
text/markdown

charset 参数可用于指定描述的字符编码。唯一合法值为 UTF-8。如果省略，则假定为 UTF-8。

其他参数可能特定于所选的子类型。例如，对于 markdown 子类型，有一个可选的 variant 参数，允许指定所使用的 Markdown 变体（如果未指定，则默认为 GFM）。目前，识别出两种变体：

GFM，用于 GitHub-flavored Markdown
CommonMark，用于 CommonMark

示例

Description-Content-Type: text/plain; charset=UTF-8

示例

Description-Content-Type: text/x-rst; charset=UTF-8

示例

Description-Content-Type: text/markdown; charset=UTF-8; variant=GFM

示例

Description-Content-Type: text/markdown

如果未指定 Description-Content-Type，则应用程序应尝试将其渲染为 text/x-rst; charset=UTF-8，如果它不是有效的 rst，则回退到 text/plain。

如果 Description-Content-Type 是一个无法识别的值，则假定的内容类型为 text/plain（尽管 PyPI 可能会拒绝任何具有无法识别值的内容）。

如果 Description-Content-Type 是 text/markdown 并且 variant 未指定或设置为无法识别的值，则假定的 variant 是 GFM。

因此，对于上面的最后一个示例，charset 默认为 UTF-8，variant 默认为 GFM，因此它等同于它之前的示例。

Keywords¶

1.0 版本新增。

一个由逗号分隔的附加关键字列表，用于帮助在更大的目录中搜索分发。

示例

Keywords: dog,puppy,voting,election

注意

规范之前显示关键字用空格分隔，但 distutils 和 setuptools 用逗号实现。这些工具已广泛使用了多年，因此更新规范以匹配事实标准更容易。

Author¶

1.0 版本新增。

一个字符串，至少包含作者的姓名；可以提供其他联系信息。

示例

Author: C. Schultz, Universal Features Syndicate,
        Los Angeles, CA <cschultz@peanuts.example.com>

Author-email¶

1.0 版本新增。

一个包含作者电子邮件地址的字符串。它可以包含 RFC-822 From: 头部合法形式的姓名和电子邮件地址。

示例

Author-email: "C. Schultz" <cschultz@example.com>

根据 RFC-822，此字段可以包含多个逗号分隔的电子邮件地址。

Author-email: cschultz@example.com, snoopy@peanuts.com

Maintainer¶

1.2 版本新增。

一个字符串，至少包含维护者的姓名；可以提供其他联系信息。

请注意，此字段旨在用于项目由原作者以外的人维护时：如果与 Author 相同，则应省略。

示例

Maintainer: C. Schultz, Universal Features Syndicate,
        Los Angeles, CA <cschultz@peanuts.example.com>

Maintainer-email¶

1.2 版本新增。

一个包含维护者电子邮件地址的字符串。它可以包含 RFC-822 From: 头部合法形式的姓名和电子邮件地址。

请注意，此字段旨在用于项目由原作者以外的人维护时：如果与 Author-email 相同，则应省略。

示例

Maintainer-email: "C. Schultz" <cschultz@example.com>

根据 RFC-822，此字段可以包含多个逗号分隔的电子邮件地址。

Maintainer-email: cschultz@example.com, snoopy@peanuts.com

License¶

1.0 版本新增。

自 2.4 版本起废弃：支持 License-Expression。

警告

从元数据 2.4 开始，License 和 License-Expression 互斥。如果两者都指定，解析元数据的工具将忽略 License，PyPI 将拒绝上传。请参阅 PEP 639。

文本指示涵盖分发的许可证，其中许可证不是“许可证”Trove 分类器中的选择。请参阅下面的 “Classifier”。此字段还可以用于指定通过 Classifier 字段命名的特定版本的许可证，或指示此类许可证的变体或例外。

示例

License: This software may only be obtained by sending the
        author a postcard, and then the user promises not
        to redistribute it.

License: GPL version 3, excluding DRM provisions

License-Expression¶

2.4 版本新增。

一个文本字符串，它是有效的 SPDX 许可证表达式，如许可证表达式中所述。

请注意，此字段中的表达式仅适用于包含此字段的分发存档（例如，源分发或 Wheel），而不适用于整个项目或与项目相关的其他文件（包括其他分发存档）。

示例

License-Expression: MIT
License-Expression: BSD-3-Clause
License-Expression: MIT AND (Apache-2.0 OR BSD-2-Clause)
License-Expression: MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)
License-Expression: GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause
License-Expression: LicenseRef-Special-License OR CC0-1.0 OR Unlicense
License-Expression: LicenseRef-Proprietary

License-File (多用途)¶

2.4 版本新增。

每个条目都是一个许可证相关文件路径的字符串表示。该路径位于项目源树内，相对于项目根目录。有关详细信息，请参阅 PEP 639。

示例

License-File: LICENSE
License-File: AUTHORS
License-File: LICENSE.txt
License-File: licenses/LICENSE.MIT
License-File: licenses/LICENSE.CC0

Classifier (多用途)¶

1.1 版本新增。

每个条目都是一个字符串，为分发提供一个分类值。分类器在 PEP 301 中描述，Python 包索引发布了当前定义的分类器的动态列表。

注意

自元数据 2.4 起，License :: 分类器的使用已弃用，请改用 License-Expression。请参阅 PEP 639。

此字段后可以跟着一个分号和一个环境标记。

示例

Classifier: Development Status :: 4 - Beta
Classifier: Environment :: Console (Text Based)

Requires-Dist (多用途)¶

1.2 版本新增。

2.1 版本有变动：字段格式规范被放宽，以接受流行发布工具使用的语法。

每个条目包含一个字符串，命名此分发所需的其他 distutils 项目。

需求字符串的格式包含一到四个部分：

一个项目名称，格式与 Name: 字段相同。唯一强制的部分。
一个逗号分隔的“额外”名称列表。这些由所需项目定义，指代可能需要额外依赖项的特定功能。这些名称必须符合 Provides-Extra: 字段指定的限制。
一个版本说明符。解析格式的工具应接受其周围的可选括号，但生成它的工具不应使用括号。
分号后的环境标记。这意味着只有在指定条件下才需要该要求。

有关允许格式的完整详细信息，请参阅 PEP 508。

项目名称应与 Python Package Index 上找到的名称相对应。

版本说明符必须遵循版本说明符中描述的规则。

示例

Requires-Dist: pkginfo
Requires-Dist: PasteDeploy
Requires-Dist: zope.interface (>3.5.0)
Requires-Dist: pywin32 >1.0; sys_platform == 'win32'

Requires-Python¶

1.2 版本新增。

此字段指定分发兼容的 Python 版本。安装工具在选择要安装的项目版本时可能会查看此字段。

该值必须符合版本说明符中指定的格式。

例如，如果一个分发使用 f-strings，那么它可以通过指定以下内容来阻止在 Python < 3.6 上安装：

Requires-Python: >=3.6

此字段不能后跟环境标记。

Requires-External (多用途)¶

1.2 版本新增。

2.1 版本有变动：字段格式规范被放宽，以接受流行发布工具使用的语法。

每个条目包含一个字符串，描述分发将要使用的系统中某些依赖项。此字段旨在作为对下游项目维护者的提示，并且没有对 distutils 分发有意义的语义。

需求字符串的格式是外部依赖项的名称，可选地后跟括号内的版本声明。

此字段后可以跟着一个分号和一个环境标记。

由于它们指的是非 Python 软件版本，因此此字段的版本号不需要符合版本说明符规范中指定的格式：它们应与外部依赖项使用的版本方案相对应。

请注意，对要使用的字符串没有特定的规则。

示例

Requires-External: C
Requires-External: libpng (>=1.5)
Requires-External: make; sys_platform != "win32"

Project-URL (多用途)¶

1.2 版本新增。

一个包含项目可浏览 URL 及其标签的字符串，用逗号分隔。

示例

Project-URL: Bug Tracker, http://bitbucket.org/tarek/distribute/issues/

标签是自由文本，限制为 32 个字符。

从 PEP 753 开始，项目元数据消费者（例如 Python Package Index）可以使用标准规范化过程来发现“知名”标签，这些标签在渲染供人类消费时可以获得特殊的呈现。请参阅元数据中的知名项目 URL。

Provides-Extra (多用途)¶

2.1 版本新增。

2.3 版本有变动： PEP 685 将有效值限制为无歧义（即无需规范化）。对于较旧的元数据版本，值限制已与 Name: 对齐，并引入了规范化规则。

一个包含可选功能名称的字符串。有效名称只能由小写 ASCII 字母、ASCII 数字和连字符组成。它必须以字母或数字开头和结尾。连字符后不能跟另一个连字符。名称仅限于匹配以下正则表达式的名称（这保证了无歧义性）：

^[a-z0-9]+(-[a-z0-9]+)*$

指定的名称可用于使依赖项依赖于是否已请求可选功能。

示例

Provides-Extra: pdf
Requires-Dist: reportlab; extra == 'pdf'

第二个分发通过将其放在方括号内来请求可选依赖项，并且可以通过用逗号 (,) 分隔来请求多个功能。对每个请求的功能评估要求，并将其添加到分发的要求集中。

示例

Requires-Dist: beaglevote[pdf]
Requires-Dist: libexample[test, doc]

功能名称 test 和 doc 保留用于标记运行自动化测试和生成文档所需的依赖项。

在没有任何 Requires-Dist: 引用它的情况下指定 Provides-Extra: 是合法的。

在为旧元数据版本编写数据时，在进行比较时，名称必须遵循用于 Name: 字段的相同规范化规则。编写元数据的工具如果两个 Provides-Extra: 条目在规范化后会发生冲突，则必须引发错误。

在读取旧元数据版本的数据时，工具应在这些字段的值在较新元数据版本下无效时发出警告。如果一个值根据任何核心元数据版本的 Name: 规则无效，则应警告用户并忽略该值以避免歧义。工具在读取旧元数据版本的无效名称时可能会选择引发错误。

Import-Name (多用途)¶

2.5 版本新增。

一个字符串，包含项目安装后独家提供的导入名称。指定的导入名称必须是有效的 Python 标识符或可以为空。此字段中列出的导入名称在项目安装在某个平台时必须可导入，且与项目版本相同。这意味着元数据必须在项目发布的所有 sdist 和 wheel 中保持一致。

导入名称后可以跟一个分号和术语“private”（例如 ; private），分号周围可以有任意数量的空格。这向工具表明该导入名称不属于项目的公共 API。

项目应列出项目独家提供的所有最短导入名称。如果任何最短名称是带点的名称，则从该名称到顶级名称的所有中间名称也应在 Import-Name 和/或 Import-Namespace 中适当地列出。

如果项目在 Import-Name 和 Import-Namespace 中列出相同的名称，工具必须因歧义而引发错误。

当两个即将安装的项目在其 Import-Name 条目中列出的名称相互重叠，或者当一个项目在 Import-Name 中有一个条目与另一个项目的 Import-Namespace 条目重叠时，工具应引发错误。这是为了避免项目意外地遮蔽另一个项目的代码。当将项目安装到现有环境中，并且与已安装的项目存在导入名称重叠时，工具可以警告或引发错误。

项目可以在其元数据中有一个空的 Import-Name 字段，以表示一个没有导入名称的项目（即分发文件中没有任何类型的 Python 模块）。

由于项目可能没有 Import-Name 元数据（要么是因为项目使用了较旧的元数据版本，要么是因为它没有指定任何元数据），因此工具无法获取有关项目提供哪些名称的信息。然而，实际上大多数项目的项目名称都与其导入名称相匹配。因此，假设以某种方式规范化为导入名称的项目名称（例如 packaging.utils.canonicalize_name(name, validate=True).replace("-", "_")）可以在需要答案时使用，这是一个合理的假设。

示例

Import-Name: PIL
Import-Name: _private_module ; private
Import-Name: zope.interface
Import-Name:

Import-Namespace (多用途)¶

2.5 版本新增。

一个字符串，包含项目安装时提供的导入名称，但非独占。指定的导入名称必须是有效的 Python 标识符。此字段用于命名空间包，其中多个项目可以贡献到同一个导入命名空间。所有在 Import-Namespace 中列出相同导入名称的项目可以一起安装而不会相互遮蔽。

导入名称后可以跟一个分号和术语“private”（例如 ; private），分号周围可以有任意数量的空格。这向工具表明该导入名称不属于项目的公共 API。

此字段中列出的导入名称在项目安装在某个平台时必须可导入，且与项目版本相同。这意味着元数据必须在项目发布的所有 sdist 和 wheel 中保持一致。

如果项目在 Import-Name 和 Import-Namespace 中列出相同的名称，工具必须因歧义而引发错误。

请注意，Import-Namespace 不能像 Import-Name 那样为空。

示例

Import-Namespace: zope
Import-Name: _private_module ; private

不常用字段¶

本节中的字段目前很少使用，因为它们的设计灵感来自 Linux 包管理系统中类似机制，而且目前尚不清楚工具应如何在 PyPI 等开放索引服务器的上下文中解释它们。

因此，流行的安装工具完全忽略它们，这反过来意味着包发布者没有动力适当地设置它们。然而，它们仍保留在元数据规范中，因为它们仍然可能对信息目的有用，并且还可以与精选包仓库结合使用以实现其最初的预期目的。

Provides-Dist (多用途)¶

1.2 版本新增。

2.1 版本有变动：字段格式规范被放宽，以接受流行发布工具使用的语法。

每个条目包含一个字符串，命名此分发中包含的 Distutils 项目。此字段必须包含在 Name 字段中标识的项目，后跟版本：名称 (版本)。

一个分发可能提供额外的名称，例如，表明多个项目已捆绑在一起。例如，ZODB 项目的源分发历史上包括了 transaction 项目，现在作为一个独立的分发提供。安装这样的源分发满足对 ZODB 和 transaction 的要求。

一个分发还可以提供一个“虚拟”项目名称，它不对应于任何单独分发的项目：这样的名称可能用于指示一个抽象功能，该功能可以由多个项目中的一个提供。例如，多个项目可能为给定 ORM 提供 RDBMS 绑定：每个项目可能声明它提供 ORM-bindings，允许其他项目仅依赖于安装了其中最多一个。

可以提供版本声明，并且必须遵循版本说明符中描述的规则。如果未指定，则会隐含分发的版本号。

此字段后可以跟着一个分号和一个环境标记。

示例

Provides-Dist: OtherProject
Provides-Dist: AnotherProject==3.4
Provides-Dist: virtual_package; python_version >= "3.4"

Obsoletes-Dist (多用途)¶

1.2 版本新增。

2.1 版本有变动：字段格式规范被放宽，以接受流行发布工具使用的语法。

每个条目包含一个字符串，描述此分发所淘汰的 distutils 项目的分发，这意味着这两个项目不应同时安装。

可以提供版本声明。版本号必须符合版本说明符中指定的格式。

此字段后可以跟着一个分号和一个环境标记。

此字段最常见的用途是项目名称更改的情况，例如 Gorgon 2.3 被整合到 Torqued Python 1.0 中。当您安装 Torqued Python 时，Gorgon 分发应该被移除。

示例

Obsoletes-Dist: Gorgon
Obsoletes-Dist: OtherProject (<3.0)
Obsoletes-Dist: Foo; os_name == "posix"

已弃用字段¶

不应使用已弃用字段，但它们是有效的元数据字段。它们可能会在核心元数据标准的未来版本中移除（届时它们将仅在指定移除前元数据版本的文件中有效）。工具在使用已弃用字段时应警告用户。

Home-page¶

1.0 版本新增。

自 1.2 版本起废弃：根据 PEP 753，请改用 Project-URL (多用途)。

一个包含分发主页 URL 的字符串。

示例

Home-page: http://www.example.com/~cschultz/bvote/

Download-URL¶

1.1 版本新增。

自 1.2 版本起废弃：根据 PEP 753，请改用 Project-URL (多用途)。

一个字符串，包含此版本分发可以下载的 URL。（这意味着 URL 不能是“.../BeagleVote-latest.tgz”之类的，而必须是“.../BeagleVote-0.45.tgz”）。

Requires¶

1.1 版本新增。

自 1.2 版本起废弃：支持 Requires-Dist

每个条目包含一个字符串，描述此包所需的其他模块或包。

需求字符串的格式与可与 import 语句一起使用的模块或包名称相同，可选地后跟括号内的版本声明。

版本声明是一系列条件运算符和版本号，以逗号分隔。条件运算符必须是“<”、“>”、“<=”、“>=”、“==”和“!=”之一。版本号必须符合 distutils.version.StrictVersion 类接受的格式：两个或三个点分隔的数字组件，末尾带有一个可选的“预发布”标签，由字母“a”或“b”后跟一个数字组成。示例版本号为“1.0”、“2.3a2”、“1.3.99”。

可以指定任意数量的条件运算符，例如，字符串“>1.0, !=1.3.4, <2.0”是合法的版本声明。

以下都是可能的需求字符串：“rfc822”、“zlib (>=1.1.4)”、“zope”。

没有规范的字符串列表；Python 社区自行选择其标准。

示例

Requires: re
Requires: sys
Requires: zlib
Requires: xml.parsers.expat (>1.0)
Requires: psycopg

Provides¶

1.1 版本新增。

自 1.2 版本起废弃：支持 Provides-Dist

每个条目包含一个字符串，描述此包安装后将提供的包或模块。这些字符串应与需求字段中使用的字符串匹配。可以提供版本声明（不带比较运算符）；如果未指定，则会隐含包的版本号。

示例

Provides: xml
Provides: xml.utils
Provides: xml.utils.iso8601
Provides: xml.dom
Provides: xmltools (1.3)

Obsoletes¶

1.1 版本新增。

自 1.2 版本起废弃：支持 Obsoletes-Dist

每个条目包含一个字符串，描述此包所淘汰的包或模块，这意味着这两个包不应同时安装。可以提供版本声明。

此字段最常见的用途是包名称更改的情况，例如 Gorgon 2.3 被整合到 Torqued Python 1.0 中。当您安装 Torqued Python 时，Gorgon 包应该被移除。

示例

Obsoletes: Gorgon

历史¶

2001 年 3 月：核心元数据 1.0 通过 PEP 241 获得批准。
2003 年 4 月：核心元数据 1.1 通过 PEP 314 获得批准。
2010 年 2 月：核心元数据 1.2 通过 PEP 345 获得批准。
2018 年 2 月：核心元数据 2.1 通过 PEP 566 获得批准。
- 添加了 Description-Content-Type 和 Provides-Extra。
- 添加了将元数据转换为 JSON 的规范方法。
- 限制了 Name 字段的语法。
2020 年 10 月：核心元数据 2.2 通过 PEP 643 获得批准。
- 添加了 Dynamic 字段。
2022 年 3 月：核心元数据 2.3 通过 PEP 685 获得批准。
- 限制了额外名称以进行规范化。
2024 年 8 月：核心元数据 2.4 通过 PEP 639 获得批准。
- 添加了 License-Expression 字段。
- 添加了 License-File 字段。
2025 年 8 月：澄清了 Dynamic 仅影响从 sdist 构建 wheel 时字段的处理方式，而不影响修改 wheel 时。
2025 年 9 月：核心元数据 2.5 通过 PEP 794 获得批准。
- 添加了 Import-Name 字段。
- 添加了 Import-Namespace 字段。
2025 年 10 月：澄清了 License-Expression 适用于包含元数据的文件，而不是项目本身。