Supporting definitions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

“Projects” are software components that are made available for integration. Projects include Python libraries, frameworks, scripts, plugins, applications, collections of data or other resources, and various combinations thereof. Public Python projects are typically registered on the Python Package Index.

“Releases” are uniquely identified snapshots of a project.

“Distribution packages” are the packaged files which are used to publish and distribute a release.

Depending on context, “package” may refer to either a distribution, or to an importable Python module that has a __path__ attribute and hence may also have importable submodules.

“Source archive” and “VCS checkout” both refer to the raw source code for a release, prior to creation of an sdist or binary archive.

An “sdist” is a publication format providing the distribution metadata and any source files that are essential to creating a binary archive for the distribution. Creating a binary archive from an sdist requires that the appropriate build tools be available on the system.

“Binary archives” only require that prebuilt files be moved to the correct location on the target system. As Python is a dynamically bound cross-platform language, many so-called “binary” archives will contain only pure Python source code.

“Contributors” are individuals and organizations that work together to develop a software component.

“Publishers” are individuals and organizations that make software components available for integration (typically by uploading distributions to an index server)

“Integrators” are individuals and organizations that incorporate published distributions as components of an application or larger system.

“Build tools” are automated tools intended to run on development systems, producing source and binary distribution archives. Build tools may also be invoked by integration tools in order to build software distributed as sdists rather than prebuilt binary archives.

“Index servers” are active distribution registries which publish version and dependency metadata and place constraints on the permitted metadata.

“Public index servers” are index servers which allow distribution uploads from untrusted third parties. The Python Package Index is a public index server.

“Publication tools” are automated tools intended to run on development systems and upload source and binary distribution archives to index servers.

“Integration tools” are automated tools that consume the metadata and distribution archives published by an index server or other designated source, and make use of them in some fashion, such as installing them or converting them to a platform specific packaging format.

“Installation tools” are integration tools specifically intended to run on deployment targets, consuming source and binary distribution archives from an index server or other designated location and deploying them to the target system.

“Automated tools” is a collective term covering build tools, index servers, publication tools, integration tools and any other software that produces or consumes distribution version and dependency metadata.

“Legacy metadata” refers to earlier versions of this metadata specification, along with the supporting metadata file formats defined by the setuptools project.

“Distro” is used as the preferred term for Linux distributions, to help avoid confusion with the Python-specific use of the term “distribution package”.

“Qualified name” is a dotted Python identifier. For imported modules and packages, the qualified name is available as the __name__ attribute, while for functions and classes it is available as the __qualname__ attribute.

A “fully qualified name” uniquely locates an object in the Python module namespace. For imported modules and packages, it is the same as the qualified name. For other Python objects, the fully qualified name consists of the qualified name of the containing module or package, a colon (:) and the qualified name of the object relative to the containing module or package.

A “prefixed name” starts with a qualified name, but is not necessarily a qualified name - it may contain additional dot separated segments which are not valid identifiers.

Integration and deployment of distributions

The primary purpose of the distribution metadata is to support integration and deployment of distributions as part of larger applications and systems.

Integration and deployment can in turn be broken down into further substeps.

• Build: the build step is the process of turning a VCS checkout, source archive or sdist into a binary archive. Dependencies must be available in order to build and create a binary archive of the distribution (including any documentation that is installed on target systems).
• Installation: the installation step involves getting the distribution and all of its runtime dependencies onto the target system. In this step, the distribution may already be on the system (when upgrading or reinstalling) or else it may be a completely new installation.
• Runtime: this is normal usage of a distribution after it has been installed on the target system.

These three steps may all occur directly on the target system. Alternatively the build step may be separated out by using binary archives provided by the publisher of the distribution, or by creating the binary archives on a separate system prior to deployment. The advantage of the latter approach is that it minimizes the dependencies that need to be installed on deployment targets (as the build dependencies will be needed only on the build systems).

The published metadata for distribution packages SHOULD allow integrators, with the aid of build and integration tools, to:

• obtain the original source code that was used to create a distribution
• identify and retrieve the dependencies (if any) required to use a distribution
• identify and retrieve the dependencies (if any) required to build a distribution from source
• identify and retrieve the dependencies (if any) required to run a distribution’s test suite

Development and publication of distributions

The secondary purpose of the distribution metadata is to support effective collaboration amongst software contributors and publishers during the development phase.

The published metadata for distributions SHOULD allow contributors and publishers, with the aid of build and publication tools, to:

• perform all the same activities needed to effectively integrate and deploy the distribution
• identify and retrieve the additional dependencies needed to develop and publish the distribution
• specify the dependencies (if any) required to use the distribution
• specify the dependencies (if any) required to build the distribution from source
• specify the dependencies (if any) required to run the distribution’s test suite
• specify the additional dependencies (if any) required to develop and publish the distribution

Metadata files

The information defined in this PEP is serialised to pysdist.json files for some use cases. These are files containing UTF-8 encoded JSON metadata.

Each metadata file consists of a single serialised mapping, with fields as described in this PEP. When serialising metadata, automated tools SHOULD lexically sort any keys and list elements in order to simplify reviews of any changes.

There are expected to be three standard locations for these metadata files:

• as a {distribution}-{version}.dist-info/pysdist.json file in an sdist source distribution archive
• as a {distribution}-{version}.dist-info/pysdist.json file in a wheel binary distribution archive
• as a {distribution}-{version}.dist-info/pysdist.json file in a local Python installation database

This file is expected to be identical in all three locations - it is generated when creating a source archive or binary archive from a source tree, and then preserved unchanged on installation, or when building a binary archive from a source archive.

Note that these metadata files MAY be processed even if the version of the containing location is too low to indicate that they are valid. Specifically, unversioned sdist archives, unversioned installation database directories and version 1.0 of the wheel specification may still provide pysdist.json files.

Other tools involved in Python distribution MAY also use this format.

Note that these metadata files are generated by build tools based on other input formats (such as setup.py and pyproject.toml) rather than being used directly as a data input format. Generating the metadata as part of the publication process also helps to deal with version specific fields (including the source URL and the version field itself).

For backwards compatibility with older installation tools, metadata 2.0 files MAY be distributed alongside legacy metadata.

Index servers MAY allow distributions to be uploaded and installation tools MAY allow distributions to be installed with only legacy metadata.

Automated tools MAY attempt to automatically translate legacy metadata to the format described in this PEP. Advice for doing so effectively is given in Appendix A.

Metadata validation

A jsonschema description of the distribution metadata is available.

This schema does NOT currently handle validation of some of the more complex string fields (instead treating them as opaque strings).

Except where otherwise noted, all URL fields in the metadata MUST comply with RFC 3986.

Metadata version

Version of the file format; "2.0" is the only legal value.

Automated tools consuming metadata SHOULD warn if metadata_version is greater than the highest version they support, and MUST fail if metadata_version has a greater major version than the highest version they support (as described in PEP 440, the major version is the value before the first dot).

For broader compatibility, build tools MAY choose to produce distribution metadata using the lowest metadata version that includes all of the needed fields.

Example:

"metadata_version": "2.0"

Generator

Name (and optional version) of the program that generated the file, if any. A manually produced file would omit this field.

Examples:

"generator": "flit"
"generator": "setuptools (34.3.1)"

Name

The name of the distribution, as defined in PEP 508.

As distribution names are used as part of URLs, filenames, command line parameters and must also interoperate with other packaging systems, the permitted characters are constrained to:

• ASCII letters ([a-zA-Z])
• ASCII digits ([0-9])
• underscores (_)
• hyphens (-)
• periods (.)

Distribution names MUST start and end with an ASCII letter or digit.

Automated tools MUST reject non-compliant names. A regular expression to enforce these constraints (when run with re.IGNORECASE) is:

^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$

All comparisons of distribution names MUST be case insensitive, and MUST consider hyphens and underscores to be equivalent.

Index servers MAY consider “confusable” characters (as defined by the Unicode Consortium in TR39: Unicode Security Mechanisms) to be equivalent.

Index servers that permit arbitrary distribution name registrations from untrusted sources SHOULD consider confusable characters to be equivalent when registering new distributions (and hence reject them as duplicates).

Integration tools MUST NOT silently accept a confusable alternate spelling as matching a requested distribution name.

At time of writing, the characters in the ASCII subset designated as confusables by the Unicode Consortium are:

• 1 (DIGIT ONE), l (LATIN SMALL LETTER L), and I (LATIN CAPITAL LETTER I)
• 0 (DIGIT ZERO), and O (LATIN CAPITAL LETTER O)

Example:

"name": "ComfyChair"

Version

The distribution’s public or local version identifier, as defined in PEP 440. Version identifiers are designed for consumption by automated tools and support a variety of flexible version specification mechanisms (see PEP 440 for details).

Version identifiers MUST comply with the format defined in PEP 440.

Version identifiers MUST be unique within each project.

Index servers MAY place restrictions on the use of local version identifiers as described in PEP 440.

Example:

"version": "1.0a2"

Summary

A short summary of what the distribution does.

This field SHOULD contain fewer than 512 characters and MUST contain fewer than 2048.

This field SHOULD NOT contain any line breaks.

A more complete description SHOULD be included as a separate file in the sdist for the distribution. Refer to the python-details extension in PEP 459 for more information.

Example:

"summary": "A module that is more fiendish than soft cushions."

Source labels

Source labels are text strings with minimal defined semantics. They are intended to allow the original source code to be unambiguously identified, even if an integrator has applied additional local modifications to a particular distribution.

To ensure source labels can be readily incorporated as part of file names and URLs, and to avoid formatting inconsistencies in hexadecimal hash representations they MUST be limited to the following set of permitted characters:

• Lowercase ASCII letters ([a-z])
• ASCII digits ([0-9])
• underscores (_)
• hyphens (-)
• periods (.)
• plus signs (+)

Source labels MUST start and end with an ASCII letter or digit.

A regular expression to rnforce these constraints (when run with re.IGNORECASE) is:

^([A-Z0-9]|[A-Z0-9][A-Z0-9._-+]*[A-Z0-9])$

A source label for a project MUST NOT match any defined version for that project. This restriction ensures that there is no ambiguity between version identifiers and source labels.

Examples:

"source_label": "1.0.0-alpha.1"

"source_label": "1.3.7+build.11.e0f985a"

"source_label": "v1.8.1.301.ga0df26f"

"source_label": "2013.02.17.dev123"

Source URL

A string containing a full URL where the source for this specific version of the distribution can be downloaded.

Source URLs MUST be unique within each project. This means that the URL can’t be something like "https://github.com/pypa/pip/archive/main.zip", but instead must be "https://github.com/pypa/pip/archive/1.3.1.zip".

The source URL MUST reference either a source archive or a tag or specific commit in an online version control system that permits creation of a suitable VCS checkout. It is intended primarily for integrators that wish to recreate the distribution from the original source form.

All source URL references SHOULD specify a secure transport mechanism (such as https) AND include an expected hash value in the URL for verification purposes. If a source URL is specified without any hash information, with hash information that the tool doesn’t understand, or with a selected hash algorithm that the tool considers too weak to trust, automated tools SHOULD at least emit a warning and MAY refuse to rely on the URL. If such a source URL also uses an insecure transport, automated tools SHOULD NOT rely on the URL.

For source archive references, an expected hash value may be specified by including a <hash-algorithm>=<expected-hash> entry as part of the URL fragment.

As of 2017, it is RECOMMENDED that 'sha256' hashes be used for source URLs, as this hash is not yet known to be vulnerable to generation of malicious collisions, while also being widely available on client systems.

For version control references, the VCS+protocol scheme SHOULD be used to identify both the version control system and the secure transport, and a version control system with hash based commit identifiers SHOULD be used. Automated tools MAY omit warnings about missing hashes for version control systems that do not provide hash based commit identifiers.

To handle version control systems that do not support including commit or tag references directly in the URL, that information may be appended to the end of the URL using the @<commit-hash> or the @<tag>#<commit-hash> notation.

Example:

"source_url": "https://github.com/pypa/pip/archive/1.3.1.zip#sha256=2dc6b5a470a1bde68946f263f1af1515a2574a150a30d6ce02c6ff742fcc0db8
"source_url": "git+https://github.com/pypa/[email protected]#7921be1537eac1e97bc40179a57f0349c2aee67d"
"source_url": "git+https://github.com/pypa/pip.git@7921be1537eac1e97bc40179a57f0349c2aee67d"

Mapping dependencies to development and distribution activities

The different categories of dependency are based on the various distribution and development activities identified above, and govern which dependencies should be installed for the specified activities:

• Required runtime dependencies:
  • unconditional dependencies
• Required build dependencies:
  • the build extra
  • the dev extra
  • If running the distribution’s test suite as part of the build process, also install the unconditional dependencies and test extra
• Required development and publication dependencies:
  • unconditional dependencies
  • the test extra
  • the build extra
  • the doc extra
  • the dev extra

The notation described in Extras (optional dependencies) SHOULD be used to determine exactly what gets installed for various operations.

Installation tools SHOULD report an error if dependencies cannot be satisfied, MUST at least emit a warning, and MAY allow the user to force the installation to proceed regardless.

See Appendix B for an overview of mapping these dependencies to an RPM spec file.

Extras

A list of optional sets of dependencies that may be used to define conditional dependencies in dependency fields. See Extras (optional dependencies) for details.

The names of extras MUST abide by the same restrictions as those for distribution names.

The following extra names are available by default and MUST NOT be declared explicitly in this field:

• all
• alldev
• build
• dev
• doc
• test

Example:

"extras": ["warmup", "tea"]

Dependencies

A list of release requirements needed to actually run this release.

Public index servers MAY prohibit strict version matching clauses or direct references in this field.

Example:

"dependencies":
  {
    "requires": ["SciPy", "PasteDeploy", "zope.interface > 3.5.0"]
  },
  {
    "requires": ["pywin32 > 1.0"],
    "environment": "sys_platform == 'win32'"
  },
  {
    "requires": ["SoftCushions"],
    "extra": "warmup"
  }
]

While many dependencies will be needed to use a project release at all, others are needed only on particular platforms or only when particular optional features of the release are needed.

To handle this, release dependency specifiers are mappings with the following subfields:

• requires: a list of requirements needed to satisfy the dependency
• extra: the name of a set of optional dependencies that are requested and installed together. See Extras (optional dependencies) for details
• environment: an environment marker defining the environment that needs these dependencies. The syntax and capabilities of environment markers are defined in PEP 508

Individual entries in the requires lists are strings using the dependency declaration format defined in PEP 508, with the exception that environment markers MUST NOT be included in the individual dependency declarations, and are instead supplied in the separate environment field.

requires is the only required subfield. When it is the only subfield, the dependencies are said to be unconditional. If extra or environment is specified, then the dependencies are conditional.

All three fields may be supplied, indicating that the dependencies are needed only when the named extra is requested in a particular environment.

Automated tools MUST combine related dependency specifiers (those with common values for extra and environment) into a single specifier listing multiple requirements when serialising metadata.

Despite this required normalisation, the same extra name or environment marker MAY appear in multiple conditional dependencies. This may happen, for example, if an extra itself only needs some of its dependencies in specific environments. It is only the combination of extras and environment markers that is required to be unique in a list of dependency specifiers.

Aside from the six standard extra categories, any extras referenced from a dependency specifier MUST be named in the Extras field for this distribution. This helps avoid typographical errors and also makes it straightforward to identify the available extras without scanning the full set of dependencies.

To reuse an extra definition as part of another extra, project releases MAY declare dependencies on themselves. To avoid infinite recursion in these cases, automated tools MUST special case dependencies from a project back onto itself.

Extension versioning

Extensions MUST be versioned, using the extension_version key. However, if this key is omitted, then the implied version is 1.0.

Automated tools consuming extension metadata SHOULD warn if extension_version is greater than the highest version they support, and MUST fail if extension_version has a greater major version than the highest version they support (as described in PEP 440, the major version is the value before the first dot).

For broader compatibility, build tools MAY choose to produce extension metadata using the lowest metadata version that includes all of the needed fields.

Required extension handling

A project may consider correct handling of some extensions to be essential to correct installation of the software. This is indicated by setting the installer_must_handle field to true. Setting it to false or omitting it altogether indicates that processing the extension when installing the distribution is not considered mandatory by the developers.

Installation tools MUST fail if installer_must_handle is set to true for an extension and the tool does not have any ability to process that particular extension (whether directly or through a tool-specific plugin system).

If an installation tool encounters a required extension it doesn’t understand when attempting to install from a wheel archive, it MAY fall back on attempting to install from source rather than failing entirely.

Metadata-Version semantics

The semantics of major and minor version increments are now specified, and follow the same model as the format version semantics specified for the wheel format in PEP 427: minor version increments must behave reasonably when processed by a tool that only understand earlier metadata versions with the same major version, while major version increments may include changes that are not compatible with existing tools.

The major version number of the specification has been incremented accordingly, as interpreting PEP 426 metadata obviously cannot be interpreted in accordance with earlier metadata specifications.

Whenever the major version number of the specification is incremented, it is expected that deployment will take some time, as either metadata consuming tools must be updated before other tools can safely start producing the new format, or else the sdist and wheel formats, along with the installation database definition, will need to be updated to support provision of multiple versions of the metadata in parallel.

Existing tools won’t abide by this guideline until they’re updated to support the new metadata standard, so the new semantics will first take effect for a hypothetical 2.x -> 3.0 transition. For the 1.x -> 2.x transition, we will use the approach where tools continue to produce the existing supplementary files (such as entry_points.txt) in addition to any equivalents specified using the new features of the standard metadata format (including the formal extension mechanism).

Switching to a JSON compatible format

The old “Key:Value” format was becoming increasingly limiting, with various complexities like parsers needing to know which fields were permitted to occur more than once, which fields supported the environment marker syntax (with an optional ";" to separate the value from the marker) and eventually even the option to embed arbitrary JSON inside particular subfields.

The old serialisation format also wasn’t amenable to easy conversion to standard Python data structures for use in any new install hook APIs, or in future extensions to the runtime importer APIs to allow them to provide information for inclusion in the installation database.

Accordingly, we’ve taken the step of switching to a JSON-compatible metadata format. This works better for APIs and is much easier for tools to parse and generate correctly. Changing the name of the metadata file also makes it easy to distribute 1.x and 2.x metadata in parallel, greatly simplifying several aspects of the migration to the new metadata format.

The specific choice of pydist.json as the preferred file name relates to the fact that the metadata described in these files applies to the distribution as a whole, rather than to any particular build. Additional metadata formats may be defined in the future to hold information that can only be determined after building a binary distribution for a particular target environment.

Changing the version scheme

See PEP 440 for a detailed rationale for the various changes made to the versioning scheme.

Source labels

The new source label support is intended to make it clearer that the constraints on public version identifiers are there primarily to aid in the creation of reliable automated dependency analysis tools. Projects are free to use whatever versioning scheme they like internally, so long as they are able to translate it to something the dependency analysis tools will understand.

Source labels also make it straightforward to record specific details of a version, like a hash or tag name that allows the release to be reconstructed from the project version control system.

Support for optional dependencies for distributions

The new extras system allows distributions to declare optional behaviour, and to use the dependency fields to indicate when particular dependencies are needed only to support that behaviour. It is derived from the equivalent system that is already in widespread use as part of setuptools and allows that aspect of the legacy setuptools metadata to be accurately represented in the new metadata format.

The additions to the extras syntax relative to setuptools are defined to make it easier to express the various possible combinations of dependencies, in particular those associated with build systems (with optional support for running the test suite) and development systems.

Support for different kinds of semantic dependencies

The separation of the five different kinds of dependency through the Extras system allows a project to optionally indicate whether a dependency is needed specifically to develop, build, test or use the distribution.

The advantage of having these distinctions supported in the upstream Python specific metadata is that even if a project doesn’t care about these distinction themselves, they may be more amenable to patches from downstream redistributors that separate the fields appropriately. Over time, this should allow much greater control over where and when particular dependencies end up being installed.

Support for metadata extensions

The new extension effectively allows sections of the metadata namespace to be delegated to other projects, while preserving a standard overal format metadata format for easy of processing by distribution tools that do not support a particular extension.

It also works well in combination with the new build extra to allow a distribution to depend on tools which do know how to handle the chosen extension, and the new extras mechanism in general, allowing support for particular extensions to be provided as optional features.

Possible future uses for extensions include declaration of plugins for other projects and hints for automatic conversion to Linux system packages.

The ability to declare an extension as required is included primarily to allow the definition of the metadata hooks extension to be deferred until some time after the initial adoption of the metadata 2.0 specification. If a release needs a postinstall hook to run in order to complete the installation successfully, then earlier versions of tools should fall back to installing from source rather than installing from a wheel file and then failing to run the expected postinstall hook.

Standard extensions

Some of the information provided by the legacy metadata system has been moved out to standard extensions defined in PEP 459.

This allows publication of the core dependency metadata in a more readily consumable format to proceed even before the full details of those extensions have been resolved.

Improved handling of project obsolescence, renames and mergers

Earlier drafts of this PEP included new Provides and Obsoleted-By fields for more robust automated notifications and tracking of project obsolescence, renames and mergers.

This isn’t an essential feature of a dependency management system, and has been deferred indefinitely as a possible future metadata extension.

MIME type registration

At some point after acceptance of the PEP, we may submit the following MIME type registration request to IANA:

• application/vnd.python.pydist+json

It’s even possible we may be able to just register the vnd.python namespace under the banner of the PSF rather than having to register the individual subformats.

String methods in environment markers

Supporting at least “.startswith” and “.endswith” string methods in environment markers would allow some conditions to be written more naturally. For example, "sys.platform.startswith('win')" is a somewhat more intuitive way to mark Windows specific dependencies, since "'win' in sys.platform" is incorrect thanks to cygwin and the fact that 64-bit Windows still shows up as win32 is more than a little strange.

Separate lists for conditional and unconditional dependencies

Earlier versions of this PEP used separate lists for conditional and unconditional dependencies. This turned out to be annoying to handle in automated tools and removing it also made the PEP and metadata schema substantially shorter, suggesting it was actually harder to explain as well.

Separate lists for semantic dependencies

Earlier versions of this PEP used separate fields rather than the extras system for test, build, documentation, and development dependencies. This turned out to be annoying to handle in automated tools and removing it also made the PEP and metadata schema substantially shorter, suggesting it was actually harder to explain as well.

Introducing friction for overly precise dependency declarations

Earlier versions of this PEP attempted to introduce friction into the inappropriate use of overly strict dependency declarations in published releases. Discussion on distutils-sig came to the conclusion that wasn’t a serious enough problem to tackle directly at the interoperability specification layer, and if it does become a problem in the future, it would be better tackled at the point where projects are uploaded to the public Python Package Index.

Disallowing underscores in distribution names

Debian doesn’t actually permit underscores in names, but that seems unduly restrictive for this spec given the common practice of using valid Python identifiers as Python distribution names. A Debian side policy of converting underscores to hyphens seems easy enough to implement (and the requirement to consider hyphens and underscores as equivalent ensures that doing so won’t introduce any name conflicts).

Allowing the use of Unicode in distribution names

This PEP deliberately avoids following Python 3 down the path of arbitrary Unicode identifiers, as the security implications of doing so are substantially worse in the software distribution use case (it opens up far more interesting attack vectors than mere code obfuscation).

In addition, the existing tools really only work properly if you restrict names to ASCII and changing that would require a lot of work for all the automated tools in the chain.

It may be reasonable to revisit this question at some point in the (distant) future, but setting up a more reliable software distribution system is challenging enough without adding more general Unicode identifier support into the mix.

Depending on source labels

There is no mechanism to express a dependency on a source label - they are included in the metadata for internal project reference only. Instead, dependencies must be expressed in terms of either public versions or else direct URL references.

Alternative dependencies

An earlier draft of this PEP considered allowing lists in place of the usual strings in dependency specifications to indicate that there are multiple ways to satisfy a dependency.

If at least one of the individual dependencies was already available, then the entire dependency would be considered satisfied, otherwise the first entry would be added to the dependency set.

Alternative dependency specification example:

["Pillow", "PIL"]
["mysql", "psycopg2 >= 4", "sqlite3"]

However, neither of the given examples is particularly compelling, since Pillow/PIL style forks aren’t common, and the database driver use case would arguably be better served by an SQL Alchemy defined “supported database driver” metadata extension where a project depends on SQL Alchemy, and then declares in the extension which database drivers are checked for compatibility by the upstream project.

Compatible release comparisons in environment markers

PEP 440 defines a rich syntax for version comparisons that could potentially be useful with python_version and python_full_version in environment markers. However, allowing the full syntax would mean environment markers are no longer a Python subset, while allowing only some of the comparisons would introduce yet another special case to handle.

Given that environment markers are only used in cases where a higher level “or” is implied by the metadata structure, it seems easier to require the use of multiple comparisons against specific Python versions for the rare cases where this would be useful.

Conditional provides

Under the revised metadata design, conditional “provides” based on runtime features or the environment would go in a separate “may_provide” field. However, it isn’t clear there’s any use case for doing that, so the idea is rejected unless someone can present a compelling use case (and even then the idea won’t be reconsidered until metadata 2.1 at the earliest).