A PyPI wheel for m0serve, and the two blind spots found on the way

[codetalcott]

ROADMAP gate 1: the install matrix. pip install m0serve && m0serve myapp:application, with no Mojo toolchain on the machine.

Two commits — fix the instrument, then build the wheel on it. They landed together because the second is what proved the first incomplete.

The headline: one wheel per platform, every CPython

m0serve does not link libpython — Mojo dlopens the interpreter at run time — so there is no CPython ABI in the archive to be compatible with. That collapses the matrix from ~10 wheels to 2. (ROADMAP gate 1 asserted the opposite; corrected.)

Verified rather than argued. One macosx_13_0_arm64 wheel:

interpreter	result
CPython 3.10, 3.11, 3.12, 3.14	m0serve 0.9.0
free-threaded 3.14t	m0serve 0.9.0

and, serving a real app across a version boundary — a wheel built on CPython 3.13 with Django 6.1 in the build venv, serving from a separate 3.11 venv:

$ curl localhost:8177/
{"django": "5.2.17", "python": "3.11.16"}

Blind spot 1: the checker could not see an executable

$ python3 scripts/ffi_portability_check.py bin/m0serve
install name  : @rpath/libKGENCompilerRTShared.dylib
dependencies  : ['/usr/lib/libSystem.B.dylib']
SELF-CONTAINED — nothing is resolved at load time.        exit 0

otool -L prints the file's own LC_ID_DYLIB before its dependencies — for a dylib. bin/m0serve is MH_EXECUTE and has none, so entries[1:] discarded the Mojo runtime. bundle_ffi.py carried the same four lines and would have copied zero runtime libraries: two tools agreeing about an artifact neither could see.

The parse now lives in scripts/binfmt.py, keyed on LC_ID_DYLIB's presence, with a --selftest covering both cases in CI.

Separately, build-serve had no post-link surgery at all, so every bin/m0serve ever built recorded a search path into the venv that produced it.

Blind spot 2: "the Linux artifact is statically linked"

The first Linux CI run refused to build, from the guard added in commit 1:

bundle-artifact: bin/m0serve needed 3 runtime libraries
(libKGENCompilerRTShared.so, ...), but the ELF path assumes static linking
and sets no RUNPATH on the copies.

That claim was measured on libm0core.so and then carried as a platform fact. The m0serve executable links the Mojo runtime dynamically on Linux exactly as on macOS. Nothing in the tooling decides by platform any more, only by what the file records: relocate_elf reads DT_NEEDED and sets a $ORIGIN DT_RUNPATH, patchelf becomes a real Linux build requirement with an error saying so, and the notices stop claiming Linux ships no Modular file.

nightly-canary.yml runs test-all — and so builds m0serve — with no apt step at all. It was relying on the runner image for libsqlite3-dev and would now have failed on patchelf. Given one.

The rest

• packaging/m0serve/ — a separate project with the only [build-system] in the repo. One in the root would make uv treat the repo as installable, and that build needs bin/m0serve, which needs the .venv uv is creating.
• A console-script shim, not .data/scripts — from there the relative path to the libraries contains the Python minor version, so the rpath would be per-interpreter and the one-wheel property lost. It also lets the exec set PATH/MOJO_PYTHON_LIBRARY/M0_CORE_LIB. os.execve keeps the pid, so the drain still works.
• scripts/wheel_tag.py measures the tag instead of copying the toolchain's, and reports the spread: Modular's runtime is built for macOS 11.0, ours for 13.0, strictest wins.
• MACOSX_DEPLOYMENT_TARGET works (measured), so builds pin 13.0. Without it the floor was macOS 26 — a property of whichever image GitHub calls macos-latest, not of this repo.
• Licensing — the wheel is the first artifact to redistribute the lightbug fork in object form, so its MIT notice must travel. licenses/LICENSE.lightbug_http.txt + NOTICE.m0serve.txt ship inside; NOTICE gains a table of which notice describes which artifact.
• Four new check-docs ratchets, each sabotage-verified: version drift, a third version copy in wheel metadata, a README pointing at 3.13t (a dead end only pyproject.toml and WSGI_VS_ASGI.md recorded), and a README documenting pip install that no CI job backs.
• README gains an architecture-qualified platform table. "Linux and macOS" unqualified is a promise pip enforces: macOS Intel is impossible (no toolchain wheel), Linux aarch64 buildable but unshipped, glibc floor excludes musl. It also becomes the PyPI front page at first upload, uneditable without a new version.

Test

839 tests, warnings unchanged at 68, smoke-ffi/serve/django/asgi/wheel green. smoke-wheel installs outside the tree on a different Python minor, serves a real app scrubbed, and asserts the binary stops working once its runtime is moved away — if it kept running the bundle would be a placebo.

Not in scope, deliberately: publishing anything. Linux aarch64 wheels, the clean-consumer release jobs, and the actual TestPyPI/PyPI upload are next.

🤖 Generated with Claude Code