Skip to content

[python] Build wheels for Linux and test the library there - #309

Merged
forfudan merged 1 commit into
mainfrom
python-linux-wheels
Aug 29, 2026
Merged

[python] Build wheels for Linux and test the library there#309
forfudan merged 1 commit into
mainfrom
python-linux-wheels

Conversation

@forfudan

Copy link
Copy Markdown
Owner

pip install decimo had nothing to install on Linux. It does now, for x86_64 and arm64, CPython 3.13 and 3.14, glibc 2.35 and later.

The wheel job builds on ubuntu-22.04 and ubuntu-22.04-arm as well as macos-14, which is two interpreters across three platforms. 22.04 rather than something newer because auditwheel names the wheel for the glibc it was built against: on 24.04 it would produce manylinux_2_39, which refuses to install on anything older.

Most of the Linux side was already written and unused. build_wheel.py has had repair_linux_wheel() since the packaging went in, the publish feature has had auditwheel and patchelf for linux-64, and hatch_build.py knows the platform tag. What was missing: linux-aarch64 in the pixi platforms and in the publish feature, and the runners in the matrix. Mojo publishes for both Linux architectures, and all three environments now resolve for all three platforms.

The library is also compiled and tested on Linux now, which is the part that makes the wheels worth installing. Every job in the test workflow ran on macOS; shipping a wheel for a platform nothing had ever run on is not a wheel anyone should install. One job builds the package on Ubuntu, runs the core suites, and builds the Python extension and runs its tests against it. It builds its own package rather than taking the artifact the macOS job uploads, since a .mojoc is compiled code and does not cross platforms, and so it does not use the shared setup action either.

What could not be checked here: this machine has no way to build for Linux, so the Linux build itself is unverified until this runs. That is what the wheel job on a pull request is for -- it builds without uploading. The failure I would expect first is the Mojo runtime libraries needing a newer glibc than 22.04's: auditwheel would tag the wheel above manylinux_2_35, the probe step would fail to install it on the same runner, and the answer would be to move the Linux builds to a newer base.

What was checked here: both workflows parse, the matrix expands to six wheels, the lock resolves default, py313 and py314 for osx-arm64, linux-64 and linux-aarch64, Mojo and argmojo have conda packages for both Linux architectures, and the macOS side is unchanged -- 1,231 Mojo tests and the Python suite pass.

pip install decimo had nothing to install on Linux. The wheel job builds on
Ubuntu 22.04 for x86_64 and arm64 as well as macOS: 22.04 because auditwheel
names the wheel for the glibc it was built against, so a newer runner would
produce a wheel that refuses to install on anything older. The Linux side of
build_wheel.py and the auditwheel and patchelf dependencies were already
there; linux-aarch64 is added to the pixi platforms and to the publish
feature, and Mojo publishes for it.

Everything in the test workflow ran on macOS. Shipping a wheel for a platform
nothing had ever run on is not a wheel anyone should install, so one job now
builds the package on Ubuntu, runs the core suites, and runs the Python tests
against a freshly built extension.
@forfudan
forfudan merged commit d1bd57b into main Aug 29, 2026
23 checks passed
@forfudan
forfudan deleted the python-linux-wheels branch August 29, 2026 20:00
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

Successfully merging this pull request may close these issues.

1 participant