Skip to content

Conversation

@DEKHTIARJonathan
Copy link

@DEKHTIARJonathan DEKHTIARJonathan commented Dec 10, 2025

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/

@DEKHTIARJonathan DEKHTIARJonathan requested a review from a team as a code owner December 10, 2025 21:54
@python-cla-bot
Copy link

python-cla-bot bot commented Dec 10, 2025

All commit authors signed the Contributor License Agreement.

CLA signed

@hugovk
Copy link
Member

hugovk commented Dec 10, 2025

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

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

@hugovk hugovk changed the title PEP 817: Wheel Variants: Beyond Platform Tags PEP 9999: Wheel Variants: Beyond Platform Tags Dec 10, 2025
@DEKHTIARJonathan
Copy link
Author

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
Copy link
Member

warsaw commented Dec 10, 2025

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

Confirmed.

@hugovk hugovk changed the title PEP 9999: Wheel Variants: Beyond Platform Tags PEP 817: Wheel Variants: Beyond Platform Tags Dec 10, 2025
@hugovk
Copy link
Member

hugovk commented Dec 10, 2025

Thanks!

@DEKHTIARJonathan You may continue with 817.

@AA-Turner AA-Turner added the new-pep A new draft PEP submitted for initial review label Dec 11, 2025
Copy link
Member

@AA-Turner AA-Turner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

A

@jezdez
Copy link

jezdez commented Dec 11, 2025

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

@DEKHTIARJonathan
Copy link
Author

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

Signed-off-by: Michał Górny <[email protected]>
Reflow the text to restore correct text width after all the inline
changes and applied suggestions.

Signed-off-by: Michał Górny <[email protected]>
Signed-off-by: Michał Górny <[email protected]>
Remove accidental double spaces that vim's `gq` introduced while I was
reflowing the text.  Thanks to @konstin for noticing.

Signed-off-by: Michał Górny <[email protected]>
enabling the optional provider or selecting the variant explicitly.


Package ABI matching

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super excited about this one by the way :D

@DEKHTIARJonathan
Copy link
Author

@hugovk @AA-Turner what needs to be done in order for the PEP to be merged ?

@AA-Turner
Copy link
Member

Sorry for my delay here. I will review the remainder of the PEP this evening (UK time).

A

@DEKHTIARJonathan
Copy link
Author

Fantastic, thanks Adam ;)

@hugovk
Copy link
Member

hugovk commented Dec 16, 2025

Note this will be the longest PEP..! Thanks Adam for reviewing.

@DEKHTIARJonathan
Copy link
Author

DEKHTIARJonathan commented Dec 16, 2025

Note this will be the longest PEP..! Thanks Adam for reviewing.

I can pay with cookies for any emotional trauma induced by this work :D

Take your time, it took us close to one year to formalize everything, build prototypes and write the PEP.
So clearly I don't think any of us expect anyone to be able to read this and understand it in a few hours ;)

@AA-Turner
Copy link
Member

I've completed my first detailed read-through (on printed paper!), but it's now firmly in the wee hours, so I'm going to continue in the morning. Writing up the review comments should go much quicker though!

A

Copy link
Member

@AA-Turner AA-Turner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry again for the further delay, this review has taken much longer than expected. I was half hoping someone else would beat me to it!

I've added several inline comments, albeit I ran out of steam a little (it is long past my bedtime!), so I might revisit the end of the PEP again.

General points:

  • I think the specification especially needs to be tightened up, to make it clear what exactly is being required of installers, builders, indexes, etc in as concicse wording as possible. The prose text in Specification should be moved elsewhere.
  • Significant chunks of text could be deleted/moved to an appendix. I've highlighted some obvious ones
  • I have found myself getting a bit confused by the jargon in the PEP, especially e.g. AoT, which might usefully be called 'static' plugins? The glossary was quite useful though.
  • Parts of the PEP appear to be saying conflicting things. This might be in my reading, but it'd be useful to clarify regardless.

So long, and thanks for all the fish cookies,
Adam

Comment on lines +49 to +50
The goal is for a familiar ``[uv] pip install <package>`` to provide
the best user experience.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The goal is for a familiar ``[uv] pip install <package>`` to provide
the best user experience.
The goal is for the obvious installation commands (``{tool} install <package>``)
to select the most appropriate wheel, and provide the best user experience.

Comment on lines +56 to +57
The Python packaging ecosystem has evolved to support increasingly
diverse computing environments. The current software ecosystem often
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"software ecosystem" here is software in general rather than just Python? Would be useful to disambiguate from "packaging ecosystem" in the previous sentence.

format cannot adequately express the diversity of features present
in modern hardware.

For example, packages such as `PyTorch <https://pytorch.org/>`_ need to
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current style is fine, but using the same PyTorch link reference with different link targets/URIs technically creates ambiguous references in the RST spec. Prefer double-trailing-underscore to fix this.

Comment on lines +78 to +85
According to the `2024 Python Developers Survey
<https://lp.jetbrains.com/python-developers-survey-2024/#purposes-for-using-python>`__,
a significant portion of respondents over the last years have been
successively using Python for scientific computing purposes, covering
such areas as Data analysis (steadily over 40% respondents), Machine
learning (grown to 40% in 2024) and Data engineering (around 30%).
Many of these use cases are directly impacted by suboptimal
packaging.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd make this para the start of Motivation, it provides a useful contextualisation

Suggested change
According to the `2024 Python Developers Survey
<https://lp.jetbrains.com/python-developers-survey-2024/#purposes-for-using-python>`__,
a significant portion of respondents over the last years have been
successively using Python for scientific computing purposes, covering
such areas as Data analysis (steadily over 40% respondents), Machine
learning (grown to 40% in 2024) and Data engineering (around 30%).
Many of these use cases are directly impacted by suboptimal
packaging.
The `2024 Python Developers Survey`__ shows that a significant proportion of
Python's users have scientific computing use-cases. This includes data analysis
(40% of respondents), machine learning (30%), and data engineering (30%).
Many of these use-cases are directly impacted by suboptimal Python packaging.
__ https://lp.jetbrains.com/python-developers-survey-2024/#purposes-for-using-python

Comment on lines +75 to +76
(``mypackage-gpu``, ``mypackage-cpu``, etc.). Each of these approaches
has significant drawbacks.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(``mypackage-gpu``, ``mypackage-cpu``, etc.). Each of these approaches
has significant drawbacks.
(``mypackage-gpu``, ``mypackage-cpu``, etc.). Each of these approaches
has significant drawbacks and potential security implications.

containing file. Its individual keys are sub-dictionaries that are
described in the subsequent sections, along with the requirements for
their presence. The tools must ignore unknown keys in the dictionaries
to permit future backwards compatible updates to the PEP. However, users
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
to permit future backwards compatible updates to the PEP. However, users
for forwards compatibility of updates to the PEP. However, users

described in the subsequent sections, along with the requirements for
their presence. The tools must ignore unknown keys in the dictionaries
to permit future backwards compatible updates to the PEP. However, users
should not introduce custom keys to avoid potential future conflicts.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
should not introduce custom keys to avoid potential future conflicts.
MUST NOT use unsupported keys to avoid potential future conflicts.

Comment on lines +1411 to +1412
it, effectively rendering the variants using its properties
incompatible. If it is ``false``, the provider is considered
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't understand this

Comment on lines +1582 to +1585
- a ``$schema`` key whose value is the URL corresponding to the schema
file supplied in the appendix of this PEP. The URL contains the
version of the format, and a new version must be added to the appendix
whenever the format changes in the future,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this over a simple version key?

Comment on lines +1935 to +1936
Plugins are implemented as Python packages. They need to expose two
kinds of Python objects at a specified API endpoint:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a hard requirement? The PEP also notes/suggests that installers reimplement (popular) provider packages, and e.g. uv is written in Rust, not Python. Does it cease to be a plugin when reimplemented?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

new-pep A new draft PEP submitted for initial review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants