Abstract

This PEP describes the changes between versions 1.2 and 2.1 of the core metadata specification for Python packages. Version 1.2 is specified in PEP 345.

It also changes to the canonical source for field specifications to the Core Metadata Specification reference document, which includes specifics of the field names, and their semantics and usage.

Fields

The canonical source for the names and semantics of each of the supported metadata fields is the Core Metadata Specification document.

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.

Version Specifiers

Version numbering requirements and the semantics for specifying comparisons between versions are defined in PEP 440. Direct references as defined in PEP 440 are also permitted as an alternative to version specifiers.

Following PEP 508, version specifiers no longer need to be surrounded by parentheses in the fields Requires-Dist, Provides-Dist, Obsoletes-Dist or Requires-External, so e.g. requests >= 2.8.1 is now a valid value. The recommended format is without parentheses, but tools parsing metadata should also be able to handle version specifiers in parentheses. Further, public index servers MAY prohibit strict version matching clauses or direct references in these fields.

Usage of version specifiers is otherwise unchanged from PEP 345.

Environment markers

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.

JSON-compatible Metadata

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:

1. The original key-value format should be read with email.parser.HeaderParser;
2. All transformed keys should be reduced to lower case. Hyphens should be replaced with underscores, but otherwise should retain all other characters;
3. The transformed value for any field marked with “(Multiple-use”) should be a single list containing all the original values for the given key;
4. The Keywords field should be converted to a list by splitting the original value on whitespace characters;
5. The message body, if present, should be set to the value of the description key.
6. The result should be stored as a string-keyed dictionary.

Summary of Differences From PEP 345

• Metadata-Version is now 2.1.
• 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.

References

This document specifies version 2.1 of the metadata format. Version 1.0 is specified in PEP 241. Version 1.1 is specified in PEP 314. Version 1.2 is specified in PEP 345. Version 2.0, while not formally accepted, was specified in PEP 426.

Copyright

This document has been placed in the public domain.

Acknowledgements

Thanks to Nick Coghlan and Thomas Kluyver for contributing to this PEP.