核心元数据规范¶
当前核心元数据文件格式（版本2.1）在中指定 PEP 566 . 它将以下规范定义为核心元数据文件格式的规范源。
以下规范中定义的字段应视为有效、完整且不可更改。所需字段为：
Metadata-VersionNameVersion
所有其他字段都是可选的。
注解
解释旧元数据： 在 PEP 566 版本说明符字段格式规范放宽了，以接受流行的发布工具使用的语法（即删除版本说明符必须用括号括起来的要求）。元数据使用者可能希望使用更宽松的格式规则，即使对于名义上小于2.1版的元数据文件也是如此。
目录
元数据版本¶
1.0 新版功能.
文件格式的版本；合法值为“1.0”、“1.1”、“1.2”和“2.1”。
使用元数据的自动化工具应在以下情况下发出警告： metadata_version 大于它们支持的最高版本，并且在以下情况下必须失败 metadata_version 主版本大于其支持的最高版本（如中所述 PEP 440 ，主版本是第一个点之前的值）。
为了更广泛的兼容性，构建工具可以选择使用包含所有所需字段的最低元数据版本来生成分发元数据。
例子：：
Metadata-Version: 2.1
名字¶
1.0 新版功能.
在 2.1 版更改: 对来自的格式添加了其他限制 PEP 508
分发的名称。名称字段是分发的主要标识符。有效名称仅由ASCII字母和数字、句点、下划线和连字符组成。它必须以字母或数字开头和结尾。分发名称仅限于与以下regex（运行时使用 re.IGNORECASE ）：
^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
例子：：
Name: BeagleVote
平台（多用途）¶
1.0 新版功能.
描述“操作系统”trove分类器中未列出的发行版所支持的操作系统的平台规范。参见下面的“分类器”。
实例：
Platform: ObscureUnix
Platform: RareDOS
支持的平台（多用途）¶
1.1 新版功能.
包含pkg-info文件的二进制分发将使用其元数据中支持的平台字段来指定编译二进制分发的操作系统和CPU。此PEP中未指定受支持平台字段的语义。
例子：：
Supported-Platform: RedHat 7.2
Supported-Platform: i386-win32-2791
描述¶
1.0 新版功能.
在 2.1 版更改: 可以在消息正文中指定此字段。
可以运行到多个段落的分发的较长描述。处理元数据的软件不应假定此字段的最大大小，尽管人们不应将其说明手册作为描述。
此字段的内容可以使用RestructedText标记写入 1. 对于使用元数据的程序，支持标记是可选的；程序也可以按原样显示字段的内容。这意味着作者在使用标记时应该保守。
为了支持与RFC822格式相关的空行和缩进行，任何CRLF字符都必须加上7个空格，后跟一个管道（“”）字符。因此，描述字段被编码成一个折叠字段，可由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。
或者，可以在消息正文中提供分发的描述（即，在标题后面的一行完全空白之后，不需要缩进或其他特殊格式）。
说明内容类型¶
2.1 新版功能.
说明分发说明中使用的标记语法（如果有）的字符串，以便工具能够智能地呈现说明。
Historically, PyPI supported descriptions in plain text and reStructuredText (reST), and could render reST into HTML. However, it is common for distribution authors to write the description in Markdown (RFC 7763) as many code hosting sites render Markdown READMEs, and authors would reuse the file for the description. PyPI didn't recognize the format and so could not render the description correctly. This resulted in many packages on PyPI with poorly-rendered descriptions when Markdown is left as plain text, or worse, was attempted to be rendered as reST. This field allows the distribution author to specify the format of their description, opening up the possibility for PyPI and other tools to be able to render Markdown and other formats.
此字段的格式与 Content-Type HTTP中的头（即： RFC 1341 ）简而言之，这意味着它有一个 type/subtype 零件，然后它可以选择具有多个参数：
格式：：
Description-Content-Type: <type>/<subtype>; charset=<charset>[; <param_name>=<param value> ...]
这个 type/subtype 部分仅具有一些法律价值：
text/plaintext/x-rsttext/markdown
这个 charset 参数可用于指定描述的字符编码。唯一的法律价值是 UTF-8 . 如果省略，则假定为 UTF-8 .
其他参数可能特定于所选的子类型。例如，对于 markdown 子类型，有一个可选的 variant 允许指定正在使用的降价变量的参数（默认为 GFM 如果未指定）。目前，可以识别两种变体：
GFMfor Github-flavored MarkdownCommonMarkfor 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
如果A Description-Content-Type 未指定，则应用程序应尝试将其呈现为 text/x-rst; charset=UTF-8 然后回到 text/plain 如果不是有效的RST。
如果A Description-Content-Type 是无法识别的值，则假定的内容类型为 text/plain （尽管pypi可能会拒绝任何具有无法识别值的内容）。
如果 Description-Content-Type 是 text/markdown 和 variant 未指定或设置为无法识别的值，则假定 variant 是 GFM .
所以对于上面的最后一个例子， charset 默认为 UTF-8 以及 variant 默认为 GFM 因此，它相当于前面的例子。
下载URL¶
1.1 新版功能.
包含可从中下载此版本分发的URL的字符串。（这意味着URL不能类似于“…/beaglewote-latest.tgz”，而是必须是“…/beaglewote-0.45.tgz”。）
作者¶
1.0 新版功能.
至少包含作者姓名的字符串；可以提供其他联系信息。
例子：：
Author: C. Schultz, Universal Features Syndicate,
Los Angeles, CA <cschultz@peanuts.example.com>
作者电子邮件¶
1.0 新版功能.
包含作者电子邮件地址的字符串。它可以在RFC-822的法律表单中包含名称和电子邮件地址。 From: 标题。
例子：：
Author-email: "C. Schultz" <cschultz@example.com>
根据RFC-822，此字段可能包含多个逗号分隔的电子邮件地址：
Author-email: cschultz@example.com, snoopy@peanuts.com
维护人员¶
1.2 新版功能.
至少包含维护者姓名的字符串；可提供其他联系信息。
请注意，此字段用于由原始作者以外的其他人维护项目时：如果它与 Author .
例子：：
Maintainer: C. Schultz, Universal Features Syndicate,
Los Angeles, CA <cschultz@peanuts.example.com>
维护者电子邮件¶
1.2 新版功能.
包含维护者电子邮件地址的字符串。它可以在RFC-822的法律表单中包含名称和电子邮件地址。 From: 标题。
请注意，此字段用于由原始作者以外的其他人维护项目时：如果它与 Author-email .
例子：：
Maintainer-email: "C. Schultz" <cschultz@example.com>
根据RFC-822，此字段可能包含多个逗号分隔的电子邮件地址：
Maintainer-email: cschultz@example.com, snoopy@peanuts.com
许可¶
1.0 新版功能.
指示包含许可证不是从“许可证”特洛夫分类器中选择的分发的许可证的文本。见 "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
分类器（多用途）¶
1.1 新版功能.
每个条目都是一个字符串，为分布提供一个单独的分类值。分类器在 PEP 301 和python包索引发布 currently defined classifiers .
此字段后面可以跟一个环境标记（分号）。
实例：
Classifier: Development Status :: 4 - Beta
Classifier: Environment :: Console (Text Based)
需要dist（多次使用）¶
1.2 新版功能.
在 2.1 版更改: 字段格式规范放宽了，以接受流行的发布工具使用的语法。
每个条目都包含一个字符串，用于命名此分发版所需的某些其他distutils项目。
需求字符串的格式包含一到四个部分：
项目名称，格式与
Name:字段。唯一的强制性部分。以逗号分隔的“额外”名称列表。这些由所需项目定义，涉及可能需要额外依赖性的特定功能。
版本说明符。分析格式的工具应该接受这周围的可选括号，但是生成它的工具不应该使用括号。
分号后的环境标记。这意味着只有在指定的条件下才需要这个要求。
见 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'
需要python¶
1.2 新版功能.
此字段指定发行版保证与之兼容的Python版本。当选择要安装的项目版本时，安装工具可能会看到这一点。
该值必须采用中指定的格式。 版本说明符 .
此字段后面可以跟一个环境标记（分号）。
实例：
Requires-Python: >=3
Requires-Python: >2.6,!=3.0.*,!=3.1.*
Requires-Python: ~=2.6
Requires-Python: >=3; sys_platform == 'win32'
需要外部（多次使用）¶
1.2 新版功能.
在 2.1 版更改: 字段格式规范放宽了，以接受流行的发布工具使用的语法。
每个条目都包含一个字符串，描述系统中要使用分发的某些依赖项。此字段旨在向下游项目维护人员提供提示，并且没有对 distutils 分布。
需求字符串的格式是外部依赖项的名称，可以选择在括号内后跟版本声明。
此字段后面可以跟一个环境标记（分号）。
因为它们指的是非python软件版本，所以这个字段的版本号是 not 要求符合 PEP 440 ：它们应该与外部依赖项使用的版本方案相对应。
注意，对于要使用的字符串没有特定的规则。
实例：
Requires-External: C
Requires-External: libpng (>=1.5)
Requires-External: make; sys_platform != "win32"
项目URL（多用途）¶
1.2 新版功能.
包含项目的可浏览URL和标签的字符串，用逗号分隔。
例子：：
Bug Tracker, http://bitbucket.org/tarek/distribute/issues/
标签是限制在32个符号以内的自由文本。
提供额外的（多用途）¶
2.1 新版功能.
包含可选功能名称的字符串。必须是有效的python标识符。可用于根据是否请求了可选功能设置依赖项。
例子：：
Provides-Extra: pdf
Requires-Dist: reportlab; extra == 'pdf'
第二个分布需要一个可选的依赖项，方法是将它放在方括号内，并可以通过用逗号（，）分隔来请求多个功能。对每个请求的特性评估需求，并将其添加到分发的一组需求中。
例子：：
Requires-Dist: beaglevote[pdf]
Requires-Dist: libexample[test, doc]
两个功能名称 test 和 doc 保留以分别标记运行自动测试和生成文档所需的依赖项。
规定是合法的 Provides-Extra: 不引用任何 Requires-Dist: .
很少使用的字段¶
本节中的字段目前很少使用，因为它们的设计灵感来自于Linux包管理系统中类似的机制，而且还不清楚工具应该如何在开放索引服务器（如 PyPI .
因此，流行的安装工具完全忽略了它们，这意味着包发布者几乎没有动力对它们进行适当的设置。但是，它们被保留在元数据规范中，因为它们仍然可能用于信息目的，并且还可以与经过管理的包存储库结合使用，以实现其最初的预期目的。
提供dist（多用途）¶
1.2 新版功能.
在 2.1 版更改: 字段格式规范放宽了，以接受流行的发布工具使用的语法。
每个条目都包含一个字符串，用于命名包含在此分发中的distutils项目。此字段 must 包括在 Name 字段，后跟version:name（version）。
分发可以提供其他名称，例如，表示多个项目已捆绑在一起。例如，源分布 ZODB 项目历史上包括 transaction 项目，现在作为单独的分发版提供。安装这样的源分发满足这两个方面的要求 ZODB 和 transaction .
分发还可以提供一个“虚拟”项目名称，该名称与任何单独分发的项目都不对应：这样的名称可用于指示可由多个项目之一提供的抽象功能。例如，多个项目可能提供RDBMS绑定供给定的ORM使用：每个项目可能声明它提供 ORM-bindings ，允许其他项目仅依赖于最多安装其中一个项目。
可以提供版本声明，并且必须遵循中描述的规则 版本说明符 . 如果未指定版本号，则将隐含分发的版本号。
此字段后面可以跟一个环境标记（分号）。
实例：
Provides-Dist: OtherProject
Provides-Dist: AnotherProject (3.4)
Provides-Dist: virtual_package; python_version >= "3.4"
过时的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"
- 2
RFC 822长标题字段：http://www.freesoft.org/cie/rfc/822/7.htm