Wheel filenames showing both manylinux_2_24 and manylinux_2_28

[daniel-larraz]

Previously, using cibuildwheel v2.23.3 with manylinux2014, my wheels had filenames like:

foo-x.y.z-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

which makes sense because manylinux2014 corresponds to glibc 2.17.

After upgrading to cibuildwheel v3.1.4, which now defaults to manylinux_2_28, the filenames changed to:

foo-x.y.z-cp310-cp310-manylinux_2_24_x86_64.manylinux_2_28_x86_64.whl

Why does the wheel filename include both manylinux_2_24 and manylinux_2_28 tags, which correspond to different minimum glibc versions? Should I expect my wheels to be compatible with glibc >= 2.24 or glibc >= 2.28?

[Czaki]

I do not know why, but it looks helpful for people who will use pip download

[daniel-larraz]

I found the following output from auditwheel:

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_24_x86_64.

A discussion about this can be found in this issue.

[daniel-larraz]

For future reference, if you know your wheel is compatible with glibc >= 2.24, you can avoid double platform tagging by explicitly setting the --plat command-line argument of Auditwheel with the AUDITWHEEL_PLAT environment variable:

CIBW_ENVIRONMENT='AUDITWHEEL_PLAT="manylinux_2_24_$(uname -m)"'

[Czaki]

For the potential user, who wants to download wheels for offline installation, and current implementations of pip and uv providing both platform tags is better. So if you don't really need this, do not strip this additional platform tag.

[daniel-larraz]

I see. I found this comment from you here. It's unfortunate that pip download doesn't handle platform tags properly.