PyPA 规范¶
除了维护 Python 打包工具链的默认实现外，Python 打包机构还负责维护用于定义这些工具之间相互作用的互操作性规范。
活跃的规格¶
由 Python 打包机构维护的互操作性规范，按照 PEP 1 的规定，作为信息性的 Python 增强提案进行跟踪。
当前有效的规范记录在 PyPA 规范 部分的 Python 打包用户指南中。
在相应的 PEP 尚未适当更新的情况下，本节还可包括对规范实施者的澄清、修正和补充指导。
规范更新过程¶
PyPA 的互操作性规范被分为两类:
提出新的规范¶
新的互操作性规范的建议应该按照 PEP 1 的规定，作为新的标准追踪 Python 增强建议来制定和提交。
这样的提议必须伴随着对 Python 包用户指南仓库 的拉取请求，针对 PyPA 规范部分，增加一个新的小节，定义新规范的目的和它在更广泛的 Python 包生态系统中的作用。
包相关的 PEP 中的 Discussions-To 标题应该设置为 Python.org Discourse 上 包 类别下专门针对该提案的新主题。
每当 distutils-sig 上提出一个新的 PEP 时，任何 PyPA 核心评审员如果认为自己有合适的经验来对该 PEP 做出最终决定，可以提出作为该 PEP 的指导委员会代表（或 “PEP 沙皇”）。如果他们的自荐被其他 PyPA 核心评审员、PyPI 主要维护者和软件包分发元数据 PEP 的默认 PEP-Delegate 接受，那么他们将有权批准（或拒绝）该 PEP。
Otherwise, the default (“standing”) PEP-Delegate depends on the area the PEP affects. The current standing delegations are:
Package Distribution Metadata PEPs: Paul Moore
Package Index Interface PEPs: Donald Stufft
For Package Distribution Metadata, the default PEP-Delegate was
originally appointed directly by Guido van Rossum as Python’s BDFL
(hence the previous use of the term BDFL-Delegate), but is now
nominated by the previous default PEP-Delegate. Any of the standing
delegates may also be a sponsor for any packaging-related PEP.
For Package Index Interfaces, the default responsible decision maker is the lead maintainer for the Python Package Index.
Provisional Acceptance¶
PyPA has its own variant of the standard library’s provisional modules, which is provisional interoperability specifications.
These are specifications which have been accepted for implementation in the core packaging tools (PyPI, pip, etc), but are still considered subject to potentially backwards incompatible amendments if real world experience indicates that there are critical problems in the interface design that make it hard to implement and/or use correctly.
When a PEP has only been provisionally accepted, this will be noted using the Provisional status in the PEP header - it will then be marked as Final after successful rollout and initial adoption of the reference implementation.
Handling fixes and other minor updates¶
The preferred approach to handling corrections and clarifications for all recent interoperability specifications is to designate in the PEP that the actively maintained version of the specification is hosted in the PyPA Specifications section of the user guide, and the PEP process is used solely to propose and review changes to the specifications, rather than serving as long term interface documentation in their own right.
For an example of this approach, see PEP 566.
This allows readability improvements that don’t affect software interoperability to be implemented using the Python Packaging User Guide’s standard pull request based workflow, in a process that more closely matches the relationship between the Python language reference and the Python Enhancement Proposals that update it.
If a change being considered this way has the potential to affect software interoperability, then it must be escalated to the distutils-sig mailing list for discussion, where it will be either approved as a text-only change, or else directed to the PEP process for specification updates.
For older PEPs, where the PEP itself serves as the reference documentation, the equivalent amendment process is to submit an issue and/or pull request against the official PEPs repo.
All enhancements proposed this way must be discussed on distutils-sig prior to amending the PEP, and any changes made after PEP acceptance must be explicitly documented in a “Changes” section in the PEP itself. For example, see:
PyPA core reviewers that are also PEP editors are responsible for deciding which of these changes can just be accepted (e.g. fixing a typo), which need to be reviewed by the relevant responsible decision maker before being accepted, and which need to be escalated to the full Python Enhancement Proposal process.
Handling major updates¶
For package distribution metadata, proposals that require backwards incompatible changes to existing interoperability specifications for package distribution metadata (and hence a new major version of the specification rather than an in-place update) are currently not permitted.
This policy has been introduced based on historical experience that such incompatibilities lead to the community sticking with older versions of the metadata format indefinitely rather than upgrading to the revised format.
For package index interfaces, major updates are handled as either Process or Standards Track PEPs targeting the Python Package Index as the reference implementation. All such PEPs that introduce backwards incompatible changes are required to define a suitable transition plan for affected software publishers and tool developers.