On Fri, 31 Aug 2018 at 07:15, Nathaniel Smith <n...@pobox.com> wrote: > > On Thu, Aug 30, 2018 at 6:52 PM, Brett Cannon <br...@python.org> wrote: > > > > > > On Thu, 30 Aug 2018 at 11:21 Nathaniel Smith <n...@pobox.com> wrote:
> >> * Make the 3 tag categories totally independent. Compute a separate set > >> for each, and then take the full cross product. > > > > > > I think Paul was hinting at this as part of his "wildcard" idea (and I > > honestly thought of this initially as well as it greatly simplifies things). > > So what would cp36-cp36m-plat expand to? > > I don't know what it means to "expand" a wheel tag. To me, the confusion really lies in the interaction of "what tags do producers set" and "what tags to consumers accept". Nearly all of the odd corner cases of tags on wheels that we see in the wild don't come from bdist_wheel without manual project intervention, and there's no validation on what they do in that case. So when we're trying to say "what should we accept" we're faced with a dilemma, because we don't really know what the options are. As a starting point, I think it would be useful to focus on what tools are allowed to *generate*. The current situation seems to me to be as follows (mostly from the PEP): 1. Python tag - can be absolutely anything (--python-tag doesn't appear to validate the value at all). In practice, py2, py3, and cpXY are the most common values AFAIK. I'd consider most other values as having had "limited testing" :-) 2. ABI tag - I don't know. But I'm pretty sure there are variations in how this works between Windows and Unix, that should be considered (IIRC, for C extensions older versions of Python on Windows produced wheels with a "none" ABI tag, but newer ones produce "cpXYm" which was a change to match Linux behaviour). 3. Platform tag - distutils.util.get_platform() (but what about manylinux, how does that end up in there?) Is there a list of valid values that get_platform() can produce? IMO, before worrying about what consumers should match, we should tie down the valid values *producers* are allowed to generate, and from that consider whether PyPI should enforce a particular set of allowed tags. Obviously, projects can do what they like in terms of randomly renaming wheels, and users can do "pip install any-old-junk.whl", but we need a baseline of what counts as "sensible" tagging schemes if we're going to enumerate acceptable tags in a consumer. Essentially this is a variation on the principle of "be strict in what you produce, and lenient in what you consume", focused on the "produce" side of the equation. My comment about wildcarding is basically a forlorn hope that if we can't be sure what we're getting, maybe the best we can do is say "well, py3-*-* sounds like it might work, and there's nothing better, so let's give it a go". But if we can tie down a definition of what constitutes a "reasonable" set of tags, enumerating what we'll accept seems more likely to succeed. Paul -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/IZ2HMXYXRSIFMJNNKZGXJATDPNHHSY5K/
