Handling unruly wheel filenames

[CasperVector]

For instance, with the following file from PyQt5, we have:

>>> import libpip2pi.commands
>>> libpip2pi.commands.file_to_package("PyQt5-5.14.0-5.14.0-cp35.cp36.cp37.cp38-abi3-manylinux1_x86_64.whl")
('PyQt5-5.14.0', '5.14.0-cp35.cp36.cp37.cp38-abi3-manylinux1_x86_64.whl')

If the wheel filename does conform to PyPI's standard, file_to_package() would definitely need to be updated. If not , PyQt5 maintainers would surely need to improve their packaging practice, but file_to_package() may also benefit from some kind of change that protects against this error. (I do not know whether this preventive change would be feasible, but I hope so.)

EDIT: on a second thought, perhaps we can simply remove the elif file_ext == ".whl": case and leave it to be handled by the final else: case in file_to_package()?

[mattmalcher]

Came across this issue with some of the nvidia packages where there is a build tag. For example, the -1 in:

https://pypi.org/simple/triton/triton-2.0.0-1-cp310-cp310-manylinux2014_x86_64.manylinux_2_17_x86_64.whl

The bits = file.rsplit("-", 4) means that the leftmost split never happens and the version number ends up in the folder name (triton-2-0-0) in the resulting /simple folder.

This means that where the package is a dependency of another package pip fails to find it.

As suggested above, commenting out the '.whl' logic and leaving it the regex in the else clause seems to do the trick. Not sure how to modify the tests to cover build tags and be sure though.

[mattmalcher]

Ah - I see this is covered in #88 (comment)