My draft for the next PEP literally has that[1]. However, I don’t think it belongs in PEP 825 for the very simple reason that we defining property compatibility is deferred into the next PEP.
Well, to be precise it’s a “SHOULD”. I think “MUST” is a bit too strong here, since I suppose tools can have valid reasons not to have that, but either way, it’s a matter for that PEP. ↩︎
The alternative is a number of extra potential error situations where the index-level metadata doesn’t match the uploaded wheels at all. Choose your poison.
You’re missing my point. If there’s no ordering data in the wheels (just the label->properties mapping) then there’s no possibility of ordering data (which would in this situation be created and uploaded separately, at the project level) not matching the wheels (because there’s nothing to match).
If we have ordering data in the wheels, then two different wheels could have different ordering data. Unless you want to somehow mandate that all wheels for a single project/version must have identical ordering metadata[1], then you have to accept that possibility. In that case, the index cannot match every wheel, even if it’s generating the data from the wheels.
I’m really struggling to understand your logic here - you seem to be assuming a workflow that the PEP doesn’t actually mandate. Maybe that workflow will be required in one of the follow-up PEPs, but if that’s the case then we’re back to the problem that PEP 825 can’t be accepted on its own, because it’s built on assumptions that don’t currently hold.
At the moment, this feels uncomfortably like the situation with “normal” wheel metadata, where uv assumes that all wheels for a given project/version have the same metadata - a reasonable assumption in a practical sense, and clearly effective for uv’s users, but it simply isn’t supported by current standards. And we’ve tried to standardise that rule, but failed. I don’t want variant metadata to end up in the same position.
The tools MUST ensure that the variant metadata across multiple variant wheels of the same package version and the index-level metadata file is consistent.
Of course, you can argue whether this can be “effectively” enforced, but it’s no different than “effectively” enforcing that the out-of-band ordering data actually matches the wheels. Either way you may get inconsistent input and need to reject it.
But enforcing multiple wheels to have the same metadata isn’t even theoretically possible. You can build two wheels for the same project/version independently, changing pyproject.toml between the two runs. There’s nothing that can stop you doing that. The best you could do is require index servers to reject uploads of wheels where the metadata doesn’t match, but that doesn’t handle static index servers, or --find-links. This is why I say that variant ordering data is index[1] level data, not wheel level.
Conversely, if “out of band” ordering data doesn’t match the wheels, who cares? That just means that there’s no override for the ordering of properties in those wheels, and the default ordering applies. Which should be a pretty normal situation anyway. Again, it’s only if wheels contain ordering data that there’s even a possibility of inconsistency, and we can’t detect that until we download the wheel, when it’s too late anyway.
But in my proposal, there is no ordering data in the wheels, so there is nothing to match.
(As a side note, “consistent” isn’t the same as “the same”. Even if data in the wheels is “consistent”, it still needs to be merged to form the index-level data).
And you can generate out-of-band ordering data that has nothing to do with the wheels. There is no real difference.
There is no default ordering of namespaces, and there can’t be.
But even that’s beside the point. What you’re basically saying is technically there exists a corner case when package maintainers could make a sequence of bad decisions (build some wheels, change metadata in inconsistent way, build more wheels, upload them all to a “dumb” index that won’t reject the result and do not verify the consistency in any way) that could lead to a unsolvable combination of metadata in different wheels, so we should instead make the process more complex, introducing additional step that definitely could go wrong in exactly the same way, except in this case it’s apparently fine. I rest my case.
Of course there can be. Alphabetic ordering would work. Yes, it might be wrong, but it would work as a fallback in the absence of any other information.
If PEP 825 chooses to say that lack of any explicit ordering is an error, then that should be stated explicitly in the PEP (if for no other reason than because the reader could otherwise assume that there is a default ordering[1]).
What I’m trying to do is explain my difficulty in understanding the PEP’s handling of ordering data as it stands. I’m clearly not managing to do so. I don’t think there’s a lot of point in continuing to debate the issue, we’re simply both going to get more frustrated.
If you don’t want to go with my suggested model of having ordering data be index-level rather than wheel-level, that’s your choice as PEP authors.
I would recommend that you review how the PEP presents this area and try to make it more understandable. At the end of the day, I need to approve or reject this PEP, and “is it clear and well-defined” is a key factor in that decision. I won’t let my difficulty understanding things be the sole deciding factor (it’s a complex area and I’m definitely not an expert) but there’s not been much evidence in the DPO discussions[2] to suggest that everyone else understands the details and it’s only me that’s struggling. Admittedly, there’s little evidence the other way around either. It would be helpful if there were more participation in this discussion…
The PEP says that default-priorities.namespace is required, and that it “MUST contain all namespaces used in variant properties.” This is as required as it gets.
It’s relatively difficult to evaluate this PEP, knowing both the prior design in 817, and not knowing how much of that prior design will be part of a related PEP later or not, when much of the prior contention of 817 is left to a future PEP now. I don’t think this PEP itself carries anything too controversial, but that doesn’t mean I feel it’s clear that the final group of PEPs as a whole will remain that way.
With regard to the issue of it being possible for per-wheel metadata existing that might conflict across wheels for metadata that really should belong at some higher level if we only had to consider a single ideal index, I said this previously, and I still think it’s as much as is reasonably possible to specify there due to how non-Pypi index cases look currently.
