PEP xxxx: Providers [rebased] - #79
Open
mgorny wants to merge 26 commits into
Open
Conversation
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>
Documentation build overview
758 files changed ·
|
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
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. |
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>
mgorny
commented
Aug 12, 2026
Comment on lines
+276
to
+281
| All variants published on a single index for a specific package version | ||
| MUST use the same provider for a given namespace. While multiple plugins | ||
| for the same namespace MAY exist across different packages, release | ||
| versions or indexes (such as when a plugin is forked due to being | ||
| unmaintained), they are mutually exclusive within any single release | ||
| version on an index. |
Author
There was a problem hiding this comment.
I wonder if we still need to say this. It's implied by the metadata consistency rules.
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>
Author
|
Okay, I'm done rereading and updating it. |
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
1 participant
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.