Removal of support for non-standard (PEP 440) wheel filenames

[notatallshaw]

What's the problem this feature will solve?

This issue it to track the the removal of supporting non-standard (PEP 440) wheel filenames.

Describe the solution you'd like

Pip will use packaging as the source of truth for the validity and parsing of wheel filenames

Alternative Solutions

None

Additional context

Previously pip implemented it's own custom logic but now will using the standard packaging library, you can check yourself by installing packaging and running:

>>> from packaging.utils import parse_wheel_filename
>>> parse_wheel_filename(my_wheel_filename)

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[testworksau]

Hello 👋🏼

I'm here as a result of spurious messages like the following in our builds:

pip 25.1 will enforce this behaviour change. A possible replacement is to rename the wheel to use a correctly normalised name (this may require updating the version in the project metadata). Discussion can be found at https://github.com/pypa/pip/issues/12938
--
DEPRECATION: Wheel filename 'our_library_name-1.7.0_PullRequest0090.7-py3-none-any.whl' is not correctly normalised. Future versions of pip will raise the following error:
Invalid wheel filename (invalid version): our_library_name-1.7.0_PullRequest0090.7-py3-none-any
 
pip 25.1 will enforce this behaviour change. A possible replacement is to rename the wheel to use a correctly normalised name (this may require updating the version in the project metadata). Discussion can be found at https://github.com/pypa/pip/issues/12938
DEPRECATION: Wheel filename 'our_library_name-1.8.0_PullRequest0091.1-py3-none-any.whl' is not correctly normalised. Future versions of pip will raise the following error:
Invalid wheel filename (invalid version): our_library_name-1.8.0_PullRequest0091.1-py3-none-any
 
pip 25.1 will enforce this behaviour change. A possible replacement is to rename the wheel to use a correctly normalised name (this may require updating the version in the project metadata). Discussion can be found at https://github.com/pypa/pip/issues/12938
DEPRECATION: Wheel filename 'our_library_name-1.9.0_PullRequest0092.1-py3-none-any.whl' is not correctly normalised. Future versions of pip will raise the following error:
Invalid wheel filename (invalid version): our_library_name-1.9.0_PullRequest0092.1-py3-none-any
 
pip 25.1 will enforce this behaviour change. A possible replacement is to rename the wheel to use a correctly normalised name (this may require updating the version in the project metadata). Discussion can be found at https://github.com/pypa/pip/issues/12938
Collecting our_library_name>=1.56.0 (from our_other_library_name==0.0)

Given we have a history of incorrectly named wheels, if we were to fix the naming sometime between now and whenever pip 25.1 drops, what outcomes would we expect to see during package resolution?

What outcomes would we expect to see if a package has compliant versions, and someone accidentally publishes a non-compliant version if compliant versions meet the version requirement constraints?

[notatallshaw]

Hi @testworksau and thanks for reporting.

Given we have a history of incorrectly named wheels, if we were to fix the naming sometime between now and whenever pip 25.1 drops, what outcomes would we expect to see during package resolution?

That's a great question, it should be that invalid file names give a warning, or an error, but the resolution moves on to valid names. It would be a great help if are you able to install pip from this PR and check what the current behavior is? You can install it like so:

pip install git+https://github.com/notatallshaw/pip.git@replace-custom-wheel-regex

What outcomes would we expect to see if a package has compliant versions, and someone accidentally publishes a non-compliant version if compliant versions meet the version requirement constraints?

The idea is that non-compliant versions should be ignored, but some feedback on a real world scenario would help a lot.

Looking at your actual wheel filename, currently the "version" part ends up including this "PullRequest" part and that's not a valid wheel filename:

>>> from pip._internal.models.wheel import Wheel
>>> my_wheel = Wheel('our_library_name-1.9.0_PullRequest0092.1-py3-none-any.whl')
>>> my_wheel.version
'1.9.0-PullRequest0092.1'

You can check the wheel filename spec: https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-format

You could add a build tag, but it is only allowed to be a number, so it would look like our_library_name-1.9.0-921-py3-none-any.whl.

[ichard26]

Well, the specification only mandates that build tags start with a digit. So if you'd like, you could include 1pullrequest9999 as the build tag. Otherwise, if you don't need to publish anywhere (except for maybe a private index), you could look into local version segments, for example 1.9.0+pullrequest9999.