I’ve started looking at the PEP. At the moment this doesn’t constitute a formal response, but it is flagging some initial concerns I have that will factor into my ultimate decision. For now, I’ve only focused on the change to the wheel filename.
Like it or not, the new filename is not backward compatible. There is no formal constraint that a platform tag can’t be numeric, so a wheel foo-1.0-1-none-any.whl is valid. Add a variant label and you get foo-1.0-1-none-any-var.whl, which will be interpreted incorrectly. And yes, I checked this:
>>> packaging.utils.parse_wheel_filename("foo-1.0-1-none-any-var.whl")
('foo', <Version('1.0')>, (1, ''), frozenset({<none-any-var @ 1209214139968>}))
This is simple to fix - the PEP just needs to require that platform tags MUST begin with a non-numeric character (which is fine, because all existing tags follow that rule). But it needs to be made explicit, both in the PEP and in the updated specs once the PEP is accepted[1].
There’s a more general point here as well - the “backward compatibility” section needs to be a lot more through on the impact of this change. The point of that section is not to claim that everything will be fine, but rather to fairly assess what issues will arise from the change, and establish that the disruption caused is acceptable, ideally discussing how the transition will be managed. For example:
- Like it or not, code will parse wheel filenames by counting the dashes. The
packaginglibrary does. I know I’ve written lots of code like that. And I don’t check the build number is valid[2]. My code will break. Probably not badly, but that’s not the point. The point is, is it worth breaking that code to implement this PEP? Do the benefits justify it? Probably[3]. - The
packagingfunctionparse_wheel_filenamewill need to change its signature which returns the parts of the wheel filename, because it might now have to return a variant label. That’s a breaking change to a public function. What’s their compatibility policy? How do they want to handle that API change? Do they have any idea how widely that function is used? - What about the transition period? Will tools that are not prepared to handle variant wheels need to pin their dependency on
packagingwhen the updated version which does handle variant wheels gets released? Will a delay in implementing variants inpackagingcause a knock-on delay in adopting the PEP? Should a PR forpackagingbe a prerequisite for adoption of the PEP?
To be clear, I’m fine with the solution adopted in the PEP. But the questions above need to be considered when approving the PEP, and IMO it’s the responsibility of the PEP authors to consider those questions, and document their conclusions in the PEP, so that I don’t have to 
To summarise, there are two concrete actions here:
- Add “platform tags must not start with a digit” to the PEP.
- Update the backward compatibility section to discuss the breakage the filename change will cause. Ideally without making the section a lot longer - most of the paragraph discussing the filename compatibility can simply be replaced, as once you discuss what breakage could occur, there’s no longer any real need to make the point about “most of the time, it’ll be OK”.
Updating the specs will be a non-trivial task - the existing specs are frustratingly vague, and incorporating PEP 825 without accidentally introducing new constraints, like the one about platform tags, will be hard. Someone should be planning what’s needed there, possibly even starting to prepare a PR for the specs repo right now. ↩︎
Nobody actually cares about build numbers
↩︎Although there’s an argument that we should design an extensible change, so we don’t have to go through this again for the next change, and the benefits are that much higher as we’ve “solved the problem once and for all”. I’d accept the response “that’s too complicated to tackle now” for that one, though. ↩︎