Use parse_wheel_filename to parse wheel filename, with fallback

[notatallshaw]

This expands and extends the deprecation warning from #12918 by first parsing with parse_wheel_filename and then falling back to the legacy regex if it fails.

In particular I found a real world example where people are using non-PEP 440 wheel filenames that would not currently get a deprecation:

pip install "en_core_web_sm @ https://huggingface.co/spacy/en_core_web_sm/resolve/main/en_core_web_sm-any-py3-none-any.whl"

[ichard26]

IIUC, this means if the packaging parser returns a different result, then pip 25.2 25.1 will be enforcing this behaviour change. The extension of the deprecation period only applies to the complete breakage of spec-violating wheel filenames.

This is probably fine as unnormalized wheel filenames will have been generally deprecated for six months already, so a behavioural change is expected. In addition, the only behaviour change I'm aware of is the normalization of project names (#12917 (comment)) which seems fine.

[ichard26]

pip 25.2

Amazing. I can never get the release numbers or dates correct. I mean pip 25.1. 🙃

[pfmoore]

Basically what's happened here is that the deprecation failed to catch all the cases it should - is that right? Normally, we'd just fix things so that we warn in the cases we missed, and push the deprecation back. But in this case we can switch to the new parser now in the cases we did warn about, which seems better.

The cost is some additional temporary code we'll need to rip out when we complete the deprecation cycle, but that seems like a small price to pay.

[pfmoore]

I can never get the release numbers or dates correct. I mean pip 25.1.

IIRC, I argued for 25.1,2,3,4 rather than 25.0,1,2,3, but others preferred the scheme we have. I always get muddled too 😕

[notatallshaw]

IIUC, this means if the packaging parser returns a different result, then pip 25.2 25.1 will be enforcing this behaviour change. The extension of the deprecation period only applies to the complete breakage of spec-violating wheel filenames.

Yes, as I found there are real world examples of people using spec-violating wheel filenames. I didn't want to outright break their use case, even if technically they weren't supported, I believe giving them a deprecation warning is appropriate.

This is probably fine as unnormalized wheel filenames will have been generally deprecated for six months already, so a behavioural change is expected. In addition, the only behaviour change I'm aware of is the normalization of project names (#12917 (comment)) which seems fine.

I don't think there's any way to get around behavioural changes in terms of migrating to standards based functions, hopefully the rest of the ecosystem is ahead of pip here in producing standard based names.

Basically what's happened here is that the deprecation failed to catch all the cases it should - is that right?

Depending what you mean by "should", the deprecation caught cases that were explicitly supported by pip's test suite, but I found real world use cases that people use pip to install wheels with invalid filenames that were not issuing a deprecation warning.

Normally, we'd just fix things so that we warn in the cases we missed, and push the deprecation back. But in this case we can switch to the new parser now in the cases we did warn about, which seems better.

It's also more efficient, we use the new parser and fallback only on exceptions, otherwise if we continue to parse using the regex first we must also always use the new parser to see if it would have raised an exception.

The cost is some additional temporary code we'll need to rip out when we complete the deprecation cycle, but that seems like a small price to pay.

Yeah, I've tried to write the code such that when we remove the old code it's a fairly clean delete.

[notatallshaw]

I've updated the news entry to better encapsulate this change.