Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

auditwheel is not idempotent #394

Open
philsc opened this issue Sep 8, 2022 · 2 comments
Open

auditwheel is not idempotent #394

philsc opened this issue Sep 8, 2022 · 2 comments

Comments

@philsc
Copy link

philsc commented Sep 8, 2022

We have a requirements file that we turn into a collection of wheels with pip wheel -r path/to/requirements.txt.
Then we run auditwheel repair on every wheel. This is useful for the wheels that pip compiled directly. But it appears to fail for wheels that pip downloaded from pypi that auditwheel has already repaired.
E.g.:

$ docker run --rm -it quay.io/pypa/manylinux_2_28_x86_64
[root@81ceff989948 /]# curl -LO 'https://files.pythonhosted.org/packages/f8/ea/ff38168d6565a8549f819699cac4d89bbc38fc5b27fb94f8e92bcd713348/numpy-1.23.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl'
[root@81ceff989948 /]# auditwheel repair --plat manylinux_2_28_x86_64 ./numpy-1.23.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
INFO:auditwheel.main_repair:Repairing numpy-1.23.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
INFO:auditwheel.main_repair:Wheel is eligible for a higher priority tag. You requested manylinux_2_28_x86_64 but I have found this wheel is eligible for manylinux_2_17_x86_64.
Traceback (most recent call last):
  File "/usr/local/bin/auditwheel", line 8, in <module>
    sys.exit(main())
  File "/opt/_internal/pipx/venvs/auditwheel/lib/python3.9/site-packages/auditwheel/main.py", line 59, in main
    rval = args.func(args, p)
  File "/opt/_internal/pipx/venvs/auditwheel/lib/python3.9/site-packages/auditwheel/main_repair.py", line 161, in execute
    out_wheel = repair_wheel(
  File "/opt/_internal/pipx/venvs/auditwheel/lib/python3.9/site-packages/auditwheel/repair.py", line 74, in repair_wheel
    raise ValueError(
ValueError: Cannot repair wheel, because required library "libgfortran-040039e1.so.5.0.0" could not be located
[root@81ceff989948 /]#

Is there a way to make auditwheel realize that it doesn't need to do any repairing here? Or is there another way to detect that auditwheel doesn't need to be run in this case?

I.e. it appears that auditwheel is not taking existing RPATH entries into account perhaps?

[root@81ceff989948 /]# unzip -v numpy-1.23.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl | grep libgfortran
 2686064  Defl:N   854901  68% 08-13-2022 18:35 8d2b4ce5  numpy.libs/libgfortran-040039e1.so.5.0.0
[root@81ceff989948 /]#
@lkollar
Copy link
Contributor

lkollar commented Sep 9, 2022

The intention was to avoid modifying already grafted libraries, but it seems this logic is broken: #389 (comment) To fix this, we need a way to mark already modified libraries.

@jvolkman
Copy link
Contributor

Given that a wheel is repaired as a single unit, maybe it's enough to just mark the wheel itself as already repaired? For instance, delvewheel includes a marker file under dist-info that it uses to determine if a wheel has already been patched.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants