|Title:||Metadata for Python Software Packages 1.3|
|Author:||Dustin Ingram <di at di.codes>|
|Discussions-To:||distutils-sig <distutils-sig at python.org>|
This PEP describes the changes between versions 1.2 and 1.3 of the core metadata specification for Python packages. Version 1.2 is specified in PEP 345.
Fields marked with "(Multiple use)" may be specified multiple times in a single PKG-INFO file. Other fields may only occur once in a PKG-INFO file. Fields marked with "(optional)" are not required to appear in a valid PKG-INFO file; all other fields must be present.
A string stating the markup syntax (if any) used in the distribution's description, so that tools can intelligently render the description.
Historically, tools like PyPI assume that a package's description is formatted in reStructuredText (reST), and fall back on plain text if the description is not valid reST.
The introduction of this field allows PyPI to support additional types of markup syntax, and not need to make this assumption.
A string containing the name of an optional feature. Must be a valid Python identifier. May be used to make a dependency conditional on whether the optional feature has been requested.
This introduction of this field allows package installation tools (such as pip) to determine which extras are provided by a given package, and so that package publication tools (such as twine) can check for issues with environment markers which use extras.
Version numbering requirements and the semantics for specifying comparisons between versions are defined in PEP 440.
Usage of version specifiers is otherwise unchanged from PEP 345.
An environment marker is a marker that can be added at the end of a field after a semi-colon (";"), to add a condition about the execution environment.
The environment marker format used to declare such a condition is defined in the environment markers section of PEP 508.
Usage of environment markers is otherwise unchanged from PEP 345.
It may be necessary to store metadata in a data structure which does not allow for multiple repeated keys, such as JSON.
The canonical method to transform metadata fields into such a data structure is as follows:
- The original key-value format should be read with email.parser.HeaderParser;
- All transformed keys should be reduced to lower case, but otherwise should retain all other characters;
- The transformed value for any field marked with "(Multiple-use") should be a single list containing all the original values for the given key;
- The Keywords field should be converted to a list by splitting the original value on whitespace characters;
- The result should be stored as a string-keyed dictionary.
Summary of Differences From PEP 345
- Metadata-Version is now 1.3.
- Fields are now specified via the Core Metadata Specification .
- Added two new fields: Description-Content-Type and Provides-Extra
- Acceptable values for the Name field are now specified as per PEP 508.
- Added canonical method of transformation into JSON-compatible data structure.
|||(1, 2, 3, 4, 5) https://packaging.python.org/specifications/core-metadata/|
This document has been placed in the public domain.
Thanks to Nick Coghlan for contributing to this PEP.