Skip to content

Ensure proper repair of wheels #20

Open
@agriyakhetarpal

Description

@agriyakhetarpal

I notice that the wheels currently have hardcoded platform tags that do not check for GLIBC version constraints or the macOS version constraints, and therefore might not be repaired fully, i.e., additional tags can be added for the Linux wheels and macOS wheels can better reflect the minimum required OSX version.

A quick experiment with delocate locally led me to find out that the minum required macOS version is macOS X 11.7 for both M-series and Intel wheels, and not 11.0 and 10.9 respectively. On my local machine (macOS), it is not possible to use auditwheel because of hard-coded checks to stop usage outside of Linux platforms, therefore, I tested using the cross-platform alternative repairwheel, which granted additional tags to some of the Linux wheels:

  1. The Linux x86_64 wheel additionally conforms to GLIBC 2.5, i.e., manylinux_2_5 (even though it's been EOLed for some while12 now). The wheel is correctly marked to have no additional dependencies, being a statically linked binary.
  2. This was similar for the Linux i686 wheel.
  3. For aarch64 and armv7l, it added the linux_1_1_aarch64 and the linux_2_17_armv7l tags for some reason, which won't be accepted on PyPI. I think that is a bug on repairwheel's side. auditwheel might be more robust in this case.

For Windows wheels, delvewheel showcased that no external DLLs are required or need to be mangled, as expected, and did not modify the wheel.

I would like to propose that an additional step in the make_wheels.py file after the wheels have been downloaded can do this action, and repairwheel can be added as a dependency in pyproject.toml. It would also make sense to provide an option through the command-line argument parser to not repair the wheels if needed, but I would argue that it's most likely better to have repaired wheels by default. Owing to how the binary inside the wheel can change during linkage, I would recommend this as an additional step instead of hardcoding the new tags in the values of the ZIG_PYTHON_PLATFORMS dictionary (those can then remain the same, or be updated).

Footnotes

  1. https://manylinuxinspector.joerick.me/

  2. https://mayeut.github.io/manylinux-timeline/

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions