PEP 817: Wheel Variants: Beyond Platform Tags

[DEKHTIARJonathan]

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
• 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
  • Rationale
  • Specification
  • Backwards Compatibility
  • Security Implications
  • How to Teach This
  • Reference Implementation
  • Rejected Ideas
  • Open Issues
• 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

CC: @mgorny @konstin @rgommers @atalman @charliermarsh @msarahan @seemethere @warsaw @dstufft @aterrel

---

📚 Documentation preview 📚: https://pep-previews--4740.org.readthedocs.build/pep-0817/

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[hugovk]

Let's renumber this to 9999 for now, we also have #4739 clashing.

@warsaw or @dstufft Please can you confirm co-authorship?

[DEKHTIARJonathan]

Oh thanks @hugovk I totally didn't see that one being published within 20min :D

Let me know which number you want me to pick and I'll do the update ;)

[warsaw]

@warsaw or @dstufft Please can you confirm co-authorship?

Confirmed.

[hugovk]

Thanks!

@DEKHTIARJonathan You may continue with 817.

[AA-Turner]

very brief review, I haven't yet read beyond the end of Motivation.

A

[jezdez]

Just a brief bystander comment: I'm so stoked to see this PEP draft published!

[DEKHTIARJonathan]

Just a brief bystander comment: I'm so stoked to see this PEP draft published!

Thanks Jannis! Took some significant amount of work but we eventually got there

[seemethere]

Super excited about this one by the way :D

[DEKHTIARJonathan]

@willingc I think you're familiar with the genesis of the work and context. Maybe skip over that for a start.

I would start from # Rationale and down: https://pep-previews--4740.org.readthedocs.build/pep-0817/#rationale

We tried extremely hard to keep the PEP as precise and short as possible specifically on the Specification section.
You can see it's a dense document because there are many many tiny details we need to formalize and explain.

So any help to make the PEP easier to read / understand / shorter is good to take.
If anything seems unclear / confusing to you, we need to update that.

[konstin]

I'd also like to highlight the difference between the normative and the non-normative section. The normative section is meant to eventually go to packaging.python.org, while the non-normative section is for the PEP discussion on why we're proposing such a big new feature, who needs it and to share the trade-offs we made in design decisions. It's has become really long, since we had a lot of input from a lot of projects and capture more the current state than the future we propose.

Similar to the other packaging PEPs, I expect the non-normative part to become a historical document, while the normative is what really needs to be written unambiguously and future-proof.

[mgorny]

I went through all the comments, and I think I've addressed them in wheelnext#32 and wheelnext#33. We'll update this PR when other authors review these changes.