PEP xxxx: Providers [rebased] - #79
Open
mgorny wants to merge 28 commits into
Open
Conversation
Documentation build overview
760 files changed ·
|
mgorny
marked this pull request as ready for review
August 12, 2026 13:25
Author
|
Updated the schema, added consistency notes, and ready for another round of review. |
mgorny
commented
Aug 12, 2026
Author
|
Okay, I'm done rereading and updating it. |
mgorny
force-pushed
the
pep-825-integration
branch
from
August 17, 2026 11:24
c7f7b0f to
29cc60d
Compare
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 primarily done via opt-in plugins that are Python packages specified in variant metadata, but can also be vendored or reimplemented by the tools. Package maintainers and users can only supply static compatibility data to avoid the need for plugins. Compared to PEP 817, the provider metadata has been largely simplified by removing all the bits deemed not strictly necessary, and provider plugins have been made opt-in (with provisions for tools to make some of them opt-out, at their leisure). The recommendations for governance of opt-out providers and building variant wheels will follow in subsequent PEPs. Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Co-authored-by: Ralf Gommers <ralf.gommers@gmail.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Co-authored-by: Jonathan DEKHTIAR <jonathan@dekhtiar.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Explicitly specify that the package name in dependency must be the same, rather than using an indirection to `plugin-api` rules. This is simple enough to inline it, and makes the spec easier to read. Technically, we could also say "normalized name" here, but I don't think we really need to allow different spellings of the same name here. Extend the rule to require it to match the first package name from the unfiltered list. This fills a corner case where the first dependency would always be filtered out: in which case the old rule would still be met but you'd have to be computing `plugin-api` from the filtered list every time. Now both approaches are valid, since they yield the same result. Also link package name normalization here, since it's the first reference to it. Signed-off-by: Michał Górny <mgorny@quansight.com>
We have just defined `static-properties`, so let's just reference it instead of trying to describe it in a mouthful. Signed-off-by: Michał Górny <mgorny@quansight.com>
Instead of listing it in passing as a minor point in "API endpoint", let's shortly describe what it is. Signed-off-by: Michał Górny <mgorny@quansight.com>
Let's describe the API first, and only list the protocol as an equivalent description of the same thing. This reduces the risk that someone will assume that they actually need to implement this via protocols. Signed-off-by: Michał Górny <mgorny@quansight.com>
Rather than saying "built wheel variant property", which could be misinterpreted as not being allowed in index-level metadata, let's just say that it appears in "`variants` dictionary". Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Unfortunately, I didn't notice that #40 was based on the
pep-wheel-variants-acceptancebranch before deleting it, so it ended up closing with no option to reopen it. I'm opening a new thread to continue working on it. I think all the comments from the previous thread have been addressed, and I've rebased it on the current PEP 825 state (per the integration branch). I still need to sync it to the changes in 825.