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.

[tgs]

Was it ever confirmed that in 25.1, pip will still complain about the invalid filenames, but still be able to install other, correct versions of the same package?

[notatallshaw]

Was it ever confirmed that in 25.1, pip will still complain about the invalid filenames, but still be able to install other, correct versions of the same package?

Yes, pip 25.1 will still be able to install wheels with invalid filenames. The deprication warning was widened to cover any wheel filename that is invalid, and failing to intstall was pushed back to pip 25.3.

[tgs]

@notatallshaw OK, got it, thank you. If I have some invalid and some valid versions of the same package, will it still be able to install the valid ones? Like you said above, "The idea is that non-compliant versions should be ignored," - is that what will happen?

[notatallshaw]

If I have some invalid and some valid versions of the same package, will it still be able to install the valid ones? Like you said above, "The idea is that non-compliant versions should be ignored," - is that what will happen?

Yes, that's the plan, otherwise it would be problematic for indexes that already have many wheels with invalid file names. I will add multiple test cases to cover this.

[tgs]

That's great, thank you!