PyOptInterface
PyOptInterface copied to clipboard
Adds wheels for linux/aarch64
Description
This PR adds wheels for linux-aarch64.
Changes
- Adds
*-manylinux_aarch64wheels build target(s). - Moves
cibuildwheelconfiguration topyproject.toml. - Modifies
{...}/setup_optimizers_linux/action.ymlto also download the optimizers for linux-aarch64.
Notes
- I was not able to add the COPT download link for linux-aarch64, as I don't have access to it.
- I did not add a separate test workflow for linux-aarch64, as no native aarch64/arm64 runner is supported by GitHub yet (for Linux that is). The wheels are built through Qemu, which is already terribly slow. Maybe the missing linux-aarch64 test workflow is an acceptable risk until official release (see GH blog post). This also raises the question whether editing the
action.ymlfile is necessary at all at this point. - I moved the build configuration to the project file for more centralized / harmonic builds. Let me know whether you like it.
- I opened another PR for highsbox (see metab0t/highsbox#5)
- I tested the wheels on an RPi and AWS instance for HiGHS and they worked fine.
I prefer to wait for the official GHA runner for Linux on ARM for reasons you have mentioned:
- QEMU is terribly slow.
- We cannot test it on every commit (this is important because I have no local hardware).
- GitHub says that they expect to begin offering Arm runners for open source projects by the end of the year, so we do not need to hurry. If someone needs the wheel, the building process of POI is quite easy because it does not depend on any solver binary (only a working C++ compiler and CMake).
Anyway, thanks for your hard work! Do you prefer to leave this PR open to get back on it later, or close it?
Yeah, that makes sense. I am happy to circle back to this when such runners become available. Feel free to ping me then. We can keep this PR open or close it until then. I don't mind. :blush:
OK, I will keep this open until we can use official GHA ARM runner.
By the way, I found out that ARM Linux can be run in VM on my M1 mac, so I can actually test it locally.
Yes, that works. Unfortunately, docker does not appear to be supported easily on the macos-14 runner (happy to be proven wrong here though - just tested it with a new workflow added in this branch, the relevant action run).
Alternatively, I have a personal self-hosted linux-aarch64 runner that would be able to cover, but that is security-wise dicey as it will get access to repo secrets when running and it runs foreign code in my basement rack. :sweat_smile: So, not sure whether it is worth it (from both our perspectives).
The CI has supported linux aarch64 using the official arm64 runner, so I am closing it now.