PEP 9999: Wheel Variants: Providers

[mgorny]

This is the second PEP split off PEP 817. Its focus is on how variant properties are governed and how their compatibility is determined. This is done either via static feature and feature value compatibility lists specified in the variant metadata, or by querying opt-in plugins that are Python packages, but can also be vendored or reimplemented by the tools. A static list can also be provided in place of querying the plugins. Additionally, an ABI Dependency Variant Provider is defined to facilitate builds of the same package against different dependency versions.

Compared to PEP 817, the provider metadata has been largely simplified by removing all the bits deemed not strictly necessary, and adjusted for the changes in PEP 825. The provider plugins have been made opt-in (with provisions for tools to make some of them opt-out). The recommendations for governance of opt-out providers and building variant wheels will follow in subsequent PEPs.

Basic requirements (all PEP Types)

• Read and followed PEP 1 & PEP 12
• File created from the latest PEP template
• PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) and PEP header
  • Tip: find the next available number with pepotron — run uvx pepotron next (or pipx install pepotron then pep next)
• Title clearly, accurately and concisely describes the content in 79 characters or less
• Core dev/PEP editor listed as Author or Sponsor, and formally confirmed their approval
• Author, Status (Draft), Type and Created headers filled out correctly
• PEP-Delegate, Topic, Requires and Replaces headers completed if appropriate
• Required sections included
  • Abstract (first section)
  • Copyright (last section; exact wording from template required)
• Code is well-formatted (PEP 7/PEP 8) and is in code blocks, with the right lexer names if non-Python
• PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
• Authors/sponsor added to .github/CODEOWNERS for the PEP

Standards Track requirements

• PEP topic discussed in a suitable venue with general agreement that a PEP is appropriate
• Suggested sections included (unless not applicable)
  • Motivation
  • Specification
  • Rationale
  • Backwards Compatibility
  • Security Implications
  • How to Teach This
  • Reference Implementation
  • Rejected Ideas
  • Open Issues
  • Acknowledgements
  • Footnotes
  • Change History
• Python-Version set to valid (pre-beta) future Python version, if relevant
• Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such
• Right before or after initial merging, PEP discussion thread created and linked to in Discussions-To and Post-History

[read-the-docs-community]

Documentation build overview

📚 pep-previews | 🛠️ Build #34679270 | 📁 Comparing 1e4b442 against latest (8766f78)

  🔍 Preview build  

6 files changed · + 2 added · ± 4 modified

+ Added

• pep-9999/index.html
• pep-9999/appendix-variant-json-schema/index.html

± Modified

• index.html
• numerical/index.html
• pep-0000/index.html
• topic/packaging/index.html

[mgorny]

@warsaw, @dstufft, could you formally confirm your approval?

[mgorny]

We've filing this "early" for PEP editor review. We'd like to defer the merging / DPO discussion a bit until we have PEP 817 update ready for the "full picture".