binary wheels generated via pyproject.toml have wrong name on linux

[Greg Couch]

I just noticed that the AlignmentHdrs and Core wheels use linux_x86_64 instead of manylinux_2_28_x86_64 for the platform. The manylinux variant is the correct one. manylinux_2_28 says that glibc 2.28 is the minimum requirement. See PEP 600.

[Zach Pearson]

TOML bundle builder doesn't interfere with wheel names at all. Probably it builds the wheel and doesn't do the additional step of checking it with ​manylinux which would give it the correct name, because of the no-docker-on-Wynton rule. To comply with PEP600 without a hack, we would build Singularity images based on the manylinux docker images and use them. Of course, *we know* they're compatible, so I can also just rename the wheel when it comes out of bundle builder. Do you have an opinion on singularity vs. just renaming them?

[Greg Couch]

Renaming is good. You can use chimerax.bundle_builder.wheel_tag.tag().

The docker images for PEP 600 are not that special. Our CentOS 8 singularity image is already equivalent to the manylinux_2_28 docker image. But the whole point to the standard is that you don't need the docker images if you follow the standard.

[Zach Pearson]

OK, renaming it is. I'll probably restrict the use of wheel_tag to Linux, because one of the motivations for not touching wheel names was that that code gave names that were too specific to universal2 Mac wheels.

I see you milestoned this for 1.9 -- Do you want to put the fix in the release? As Tom always says point releases see more usage than daily builds, so IMO people using 1.8 to build their bundles should expect to get the right wheel tag.

[Greg Couch]

It would be okay to do it now, but it is not required. I am surprised that the same code doesn't work on the Mac. The specific wheel name indicates the minimum OS runtime needed to run the wheel. A less specific wheel name allows the wheel to be installed on an incompatible system.

[Zach Pearson]

In this case I couldn't figure out how to make that code give universal2 wheels the universal2 tag. It would always give those wheels either the x86_64-mac or arm64-mac tags, which meant you couldn't install a wheel on the other architecture even if it was compatible. setuptools always gives the correct tag, this manylinux thing notwithstanding.

[Greg Couch]

Added an argument to bundle_builder.wheel_tag.tag() to get the most specific universal platform wheel tag.

[Zach Pearson]

Here's my proposed solution:

• Add a 'release' argument to 'devel build' that enables or disables auditing Linux wheels
• if 'release=True', run 'auditwheel repair --plat manylinux_2_28_x86_64 --only-plat ${wheel}' after building the wheel

That requires adding auditwheel to bundle builder's dependencies.

If release=True but a wheel cannot be given the correct tags, we simply warn the user that the wheel is ineligible for release on the Toolshed.

I have the bundle builder side of this working in my local build.

[Zach Pearson]

​This commit runs auditwheel on a built TOML linux project if the devel command has release true, and assigns it the manylinux_2_28 tag if possible, warning the user if the wheel will be incompatible with ChimeraX.

Running auditwheel with --only-plat prevents auditwheel from naming the wheel with both the absolute lowest compatible libc version and the requested version.

​This commit adds release to the core devel command.

​This commit adds it to Makefile.bundle

During testing I was surprised that when I built arrays on Ubuntu 22.04 it was assigned the manylinux_2_28 tag; I expected it to say it was not compatible with anything under 2.35. I re-ran auditwheel without --only-plat, which resulted in an even lower 2_24 tag. I pulled that wheel into a Rocky 8 VM and unpacked it in a Rocky 8 ChimeraX, then started it in nogui mode and ran 'open 5y5s'. But it looks like auditwheel was telling the truth: it didn't crash or fail to start.