Wheels for musl (Alpine)

Packaging
36

Now that I’m on a computer with docker, I took a quick peek at the popular alpine image, and it appears that it ships with literally nothing except musl, openssl, libz, and libtls-standalone (which appears to be some funky thing forked from part of libressl):

❯ docker run --rm -it alpine ls /lib /usr/lib
/lib:
apk                    libc.musl-x86_64.so.1  libz.so.1.2.11
firmware               libcrypto.so.1.1       mdev
ld-musl-x86_64.so.1    libssl.so.1.1          modules-load.d
libapk.so.3.12.0       libz.so.1              sysctl.d

/usr/lib:
engines-1.1                 libtls-standalone.so.1
libcrypto.so.1.1            libtls-standalone.so.1.0.0
libssl.so.1.1               modules-load.d

OpenSSL has traditionally been really bad at ABI compatibility, and I doubt many packages are using this libtls-standalone thing since it appears to be unique to alpine. And musl and libz both have extremely stable ABIs and it’s safe to assume they’re available on every musl-based distribution.

So my updated suggestion is:

  • Write a quick PEP for musllinux_X_Y tags, where the tag means that the wheel should work on any real-world distro that uses musl X.Y or later. You can cite the perennial manylinux PEP for most of the details. This PEP could honestly be like 3 paragraphs long. Maybe less.
  • Update pip to understand when it’s running under musl X.Y or later. This will require grossness but it’s doable. Maybe later something like bpo-43112 will make it less gross, but worry about that some other time.
  • Update auditwheel to understand musllinux_X_Y tags
  • Maybe provide some standard musllinux docker images, though tbh these would probably just be the standard python:alpine images + gcc + auditwheel, so the need is a lot less urgent than for manylinux
5 Likes