Skip to content

PEP 825: clarify metadata scoping#48

Open
mgorny wants to merge 1 commit intopep-wheel-variants-acceptancefrom
pep-825-scoping
Open

PEP 825: clarify metadata scoping#48
mgorny wants to merge 1 commit intopep-wheel-variants-acceptancefrom
pep-825-scoping

Conversation

@mgorny
Copy link
Copy Markdown

@mgorny mgorny commented Apr 23, 2026

Explicitly mention that the variant metadata is normally scoped to a single wheel, but at the level of index it is scoped to a particular package version on that index. Clarify that people cannot assume that the labels or properties mean the same thing across different package versions or indexes.


📚 Documentation preview 📚: https://wheelnext-peps--48.org.readthedocs.build/

Explicitly mention that the variant metadata is normally scoped to a
single wheel, but at the level of index it is scoped to a particular
package version on that index.  Clarify that people cannot assume that
the labels or properties mean the same thing across different package
versions or indexes.

Signed-off-by: Michał Górny <mgorny@quansight.com>
@read-the-docs-community
Copy link
Copy Markdown

Comment thread peps/pep-0825.rst
}


Scoping
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I wouldn't say anything about this, that's just something for the tools to decide. A tool may or may not want to make additional assumptions here. If pip decides that all wheels with the same name it sees are identical, than that's a pip choice. I'd not express any opinion about this in this PEP, as the specs currently express no opinion on what to do if you see two wheels with the same name without variants. I'd instead point this out in the discussion: We're not opining on this, as this is not a problem that is created or notably changed through variants, nor is it currently in the domain of any PEP.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

But it is different. Platform compatibility tags have consistent global meaning, variant labels do not. Variant labels are more closely related to tags than to project names, and as such people are more likely to assume consistency when it is not guaranteed.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

You're right platform tags isn't a good example, but the same applies already with METADATA, where we have this debate already (and there was a strong case made that you cannot assume consistency because pip doesn't).

Comment thread peps/pep-0825.rst
index for the package version in question.

Index-level metadata is scoped to a particular package version on a
particular index. The tools MUST NOT assume that the same label used
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Similarly here, I say assuming that is a bad idea, but how you implement support for multiple indices is your choice. uv intentionally doesn't allow merging indices without unsafe- flags, but other tools may want to support it.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants