Wheel name validation broken

[mara004]

It seems like the new wheel release has broken pypdfium2 installation because wheels with multiple .-separated tags are now erroneously considered invalid:

File "/home/mara/projects/pypdfium2/setupsrc/pl_setup/setup_base.py", line 77, in mkwheel
  setuptools.setup(
File "/tmp/pip-build-env-jzav0p36/overlay/lib/python3.10/site-packages/setuptools/__init__.py", line 87, in setup
  return distutils.core.setup(**attrs)
File "/tmp/pip-build-env-jzav0p36/overlay/lib/python3.10/site-packages/setuptools/_distutils/core.py", line 185, in setup
  return run_commands(dist)
File "/tmp/pip-build-env-jzav0p36/overlay/lib/python3.10/site-packages/setuptools/_distutils/core.py", line 201, in run_commands
  dist.run_commands()
File "/tmp/pip-build-env-jzav0p36/overlay/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 968, in run_commands
  self.run_command(cmd)
File "/tmp/pip-build-env-jzav0p36/overlay/lib/python3.10/site-packages/setuptools/dist.py", line 1217, in run_command
  super().run_command(command)
File "/tmp/pip-build-env-jzav0p36/overlay/lib/python3.10/site-packages/setuptools/_distutils/dist.py", line 987, in run_command
  cmd_obj.run()
File "/tmp/pip-build-env-jzav0p36/overlay/lib/python3.10/site-packages/wheel/bdist_wheel.py", line 385, in run
  with WheelFile(wheel_path, "w", self.compression) as wf:
File "/tmp/pip-build-env-jzav0p36/overlay/lib/python3.10/site-packages/wheel/wheelfile.py", line 45, in __init__
  raise WheelError(f"Bad wheel filename {basename!r}")
wheel.cli.WheelError: Bad wheel filename 'pypdfium2-3.6.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl'
[end of output]

pypdfium2-team/pypdfium2#155

I think something's wrong with your WHEEL_INFO_RE regex.

[mara004]

Presumably introduced with commit 88f02bc?

[jacobdr]

It might even be more severe possibly? The example below is not even a multi-tag

• I pulled an example off of the PEP-491 -- specifically distribution-1.0-1-py27-none-any.whl
• took the WHEEL_INFO_RE -- which appears to be re.compile('^(?P<namever>(?P<name>[^-]+?)-(?P<ver>[^-]+?))(-(?P<build>\\d[^-]*))?\n -(?P<pyver>[^-]+?)-(?P<abi>[^-]+?)-(?P<plat>[^.]+?)\\.whl$', re.VERBOSE)
• Popped that in regex101
• And did not get a match....

[agronholm]

This is caused by an unfortunate error in the platform part of the regex. I have a fix almost ready and will publish a patch release very soon.

And did not get a match....

>>> import re
>>> WHEEL_INFO_RE = re.compile(
...    r"""^(?P<namever>(?P<name>[^-]+?)-(?P<ver>[^-]+?))(-(?P<build>\d[^-]*))?
...     -(?P<pyver>[^-]+?)-(?P<abi>[^-]+?)-(?P<plat>[^.]+?)\.whl$""",
...    re.VERBOSE,
... )
>>> WHEEL_INFO_RE.match("distribution-1.0-1-py27-none-any.whl")
<re.Match object; span=(0, 36), match='distribution-1.0-1-py27-none-any.whl'>

[mara004]

Thanks for the quick fix!
Looking at the PyPI history, you may want to consider yanking v0.38.1 as well.

[mara004]

pip also has such a regex:
https://github.com/pypa/pip/blob/90f51db1a32592430f2e4f6fbb9efa7a3a249423/src/pip/_internal/models/wheel.py#L15

I think it differs slightly. Is that on purpose?

[agronholm]

The differences are negligible, and I have little interest in fine tuning this regex since wheel name parsing will be delegated to packaging from v1.0.0 forward.

[zhuofeng6]

Why is the file name not completely matched?

>>> import re
>>> WHEEL_INFO_RE = re.compile(
...     r"""^(?P<namever>(?P<name>[^\s-]+?)-(?P<ver>[^\s-]+?))(-(?P<build>\d[^\s-]*))?
...      -(?P<pyver>[^\s-]+?)-(?P<abi>[^\s-]+?)-(?P<plat>\S+)\.whl$""",
...     re.VERBOSE,
... )
>>> WHEEL_INFO_RE.match("pypdfium2-3.6.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl")
<re.Match object; span=(0, 71), match='pypdfium2-3.6.0-py3-none-manylinux_2_17_x86_64.ma>

[pfmoore]

It's just the repr of the match object:

>>> import re
>>> WHEEL_INFO_RE = re.compile(
...     r"""^(?P<namever>(?P<name>[^\s-]+?)-(?P<ver>[^\s-]+?))(-(?P<build>\d[^\s-]*))?
...      -(?P<pyver>[^\s-]+?)-(?P<abi>[^\s-]+?)-(?P<plat>\S+)\.whl$""",
...     re.VERBOSE,
... )
>>> WHEEL_INFO_RE.match("pypdfium2-3.6.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl")
<re.Match object; span=(0, 71), match='pypdfium2-3.6.0-py3-none-manylinux_2_17_x86_64.ma>
>>> m = WHEEL_INFO_RE.match("pypdfium2-3.6.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl")
>>> m.group(0)
'pypdfium2-3.6.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl'

[xiaoge1001]

Presumably introduced with commit 88f02bc?

I think it's introduced with commit 88f02bc.

We can use the following method to test：
wheel unpack "pypdfium2-3.6.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl"

if wheel with commit 88f02bc （and without 4419390）, the result is:
Bad wheel filename 'pypdfium2-3.6.0-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl'

if wheel without commit 88f02bc, the result is:
Unpacking to: ./pypdfium2-3.6.0...OK