My concern is slightly different. Ultimately, the issue I have is a theoretical one - by publishing release-level data in wheels, we create a built-in issue of having multiple sources of truth. Either every wheel in a release must have the same variant data, or we need a reliable way to merge wheel-level data to create a “superset” release-level picture that remains consistent with what’s in the individual wheels.
By choosing to require every wheel to have the same data, we have imposed a constraint that is (in theory, at least) impossible to enforce without central control over the building of wheels.
The problem is that my concern is based on theory, not on practical issues. I have no real idea if there are use cases that would be impacted by the “all data must be the same” constraint. We can, of course, start with that constraint and relax it later, but that would potentially involve a follow-up PEP and a bunch of backward compatibility questions (tools could legitimately raise an error if they encounter inconsistent data, and those tools would then be wrong if we relaxed the requirement). So I’d like to ensure that we’ve done the best we can to make sure the consistency constraint is viable.
My example of a 3rd party publisher is invented - I have no direct experience of doing this. So the point of the example is to get people to explore the practical consequences of the consistency constraint. And to the extent that we’re having this conversation, it’s done its job. But as far as being a real use case is concerned, it’s really just a plausible scenario in my mind. I’m having some offline discussions to try to establish if there is a real example of this scenario, but it’s hard to be sure as many reasonable examples would be closed-source.
My understanding is that “pick the index that serves the variants you want” is considered a bad solution. It’s basically what pytorch do right now, and if it was sufficient, we wouldn’t be having the debate about variants. If that understanding is wrong, I’d like a clearer explanation of how this scenario differs from the pytorch one (I’m discounting questions of scale such as “pytorch has a lot more wheels to deal with”, because they don’t feel like design-level questions).
Also, I’m not sure what mirroring would mean in practice. If users were installing a mix of wheels with variants and “normal” wheels, would all of the normal wheels also need to be mirrored? Because if not, we have the problem that installers would still see wheels from both indexes (the dedicated one that mirrors the patched variants, and the source one). And short of standardising some sort of index priority algorithm, users have no way of ensuring that the install will prefer the patched variants over the source builds (except by using some sort of tool-specific ordering mechanism, and crucially pip doesn’t yet have such a mechanism).
I don’t really understand how this would work. The “axis of a multidimensional matrix” framing feels very abstract to me. Are we talking about a command line UI that said “add foo to the list in default-priorities.namespace” along with adding foo entries to the feature and property tables? Because getting that UI right seems like it would be pretty complex, and speaking for pip, I could easily imagine that we’d say the cost of designing and using something isn’t worth the limited benefits it would offer. I’d be concerned about dismissing a valid use case[1] as something to be handled by a tool-specific UI, if we’re not sure that tools will be willing to implement such a UI…
I’m fine with user opt-in, although there was a lot of talk previously about “having pip install pytorch just work”, and in the wider context, I think we need to be careful about what “just work” means in practice. I have a feeling that the PEP authors have a picture of what it means for variants to make things “just work” that they haven’t yet communicated very clearly.
No, I’m happy with the idea that there’s one owner for the data for a given project on an index. What I’m less comfortable is putting PyPI in a privileged position where project owners on PyPI have control over what people publishing that project on another index can do.
I’m aware that there’s a conflict here - for security reasons[2] people want to feel that if they trust a project’s owners, they can trust the project. But on the other hand, installers[3] expect users to trust the indexes they use, and by implication, they do not delegate that trust to any form of cross-index authority. With the ecosystem as it stands right now, there is no cross-index authority, and implying that it exists is an unjustified assumption, IMO.
I apologise for the fact that all of this feels very much like a lot of fuss over a very theoretical edge case. In many ways it is, and we could all be a lot happier if we just said “variant data needs to be consistent, let’s just move on”. But I’ve had a lot of experience with the standards process, and the most difficult problems we encounter tend to be with edge cases where a standard made assumptions that seemed very plausible at the time, but didn’t state them very clearly, and it turned out that what was “obvious” to the standard authors was interpreted completely differently by actual users. So I want to make sure we’ve thought these things through, and are as clear as we can be on the implications.
But at the end of the day, if we can say “yes, we understand the implications and are happy with them, and we can explain them clearly enough that there won’t be misunderstandings”, then I’m perfectly fine with going with a consistency requirement.