[qwertox]

musl really becomes a pain if you work a lot with Python. You can't use wheels, which means you will have to compile everything yourself, which sometimes takes ages, and you're not guaranteed that it won't have unnoticeable errors.

My biggest issue was with the 3.12 -> 3.13 transition, when musl got upgraded to 1.2 and with it "musl 1.2 uses new time64-compatible system calls". This broke so many things for me without me knowing, like nginx having as the datetime in the logs the unix epoch. All continued to work, but everything related to timestamps was completely messed up, on 32 bit OS due to running on Raspberry Pis.

This was the moment where I decided to stick to debian-slim, and only very specific containers will continue running on Alpine. Before that it was my default container OS.

Also there is no reliability in packages getting updated, sometimes they just disappear in the next version. But these things are rare occurrences, which only are then nerve wracking when you are confronted with them. For 90% of the cases Alpine is one of the most awesome container OSs.

[wahern]

OpenBSD went through a similar transition, except they didn't even try to maintain ABI compatibility. See https://www.openbsd.org/55.html and https://www.openbsd.org/faq/upgrade55.html, the latter describing the rare "flag day" event. Long term this was good for OpenBSD as it saved a ton of unnecessary cruft and complexity that would have haunted OpenBSD for years if not decades, endlessly taxing developers' time, especially of core developers. And it was an inducement for all developers, those working on OpenBSD (core and ports teams) as well as those targeting OpenBSD, to carefully review code for 64-bit time_t safety. But it necessarily required that the broader community shoulder a large part of the transition burden.

Sometimes it's better to power through with a massive labor effort than to try to use fancy hacks to shield people from latent problems. All things considered, it doesn't sound like the Alpine transition was that bad. But it's the type of thing that most Linux users and developers are not accustomed to, at least those who don't remember the very early years. Ironically, musl libc might not exist if glibc hadn't accumulated so much complexity trying to maintain strong ABI compatibility.

IMO, small prices to pay for free software and Free Software.

[fmajid]

There is a lot of affinity between Alpine and OpenBSD. That's a good thing in my book.

I build my entire development stack from source and don't rely on OS packages for it, and I absolutely refuse to use binary compiled Python wheels, so Alpine's lack of them is actually a feature as far as I am concerned. I dealt with the musl quirks.

[scandinavian]

> You can't use wheels

musl wheel support was added some time ago:

https://github.com/pypa/packaging/releases/tag/21.0

No idea how many packages actually build musl wheels though. From a quick glance at least cryptography and lxml has musl wheels.

[senknvd]

Unfortunately, Alpine patched their version of Python in a way that is incompatible with musllinux wheels so we are back to where we started until Alpine Linux 3.16 in 2022[1].

EDIT: I spoke too soon. Apparently, they have decided to amend the patch in a way that is both backwards-compatible and compatible with musllinux wheels[2]. Hopefully, it will roll out soon.

[1]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13227 [2]: https://bugs.python.org/msg406939

[lonjil]

The fix has now been pushed to the 3.15 branch.

[yieldgap]

thanks, I had been scouring the internet for something on this. Didn't expect to come across it on HN

[_ikke_]

This will be addressed though

[rcarmo]

This still works for me:

https://github.com/insightfulsystems/alpine-python/blob/5a34...

But I haven’t tested today’s version yet.

[rcarmo]

Actually, you can run most wheels just fine if you do this: https://github.com/insightfulsystems/alpine-python/blob/5a34...

You just need to know how :)

[qwertox]

I did know this, but it wasn't 100% reliable, see https://github.com/grpc/grpc/issues/18150

Regarding the "runs just fine", this is not guaranteed. I certainly do check if it is working, and if it is, and it is a small service or just a containerized tool, then I'll use it. Like using GDAL to perform some reprojections and renderings where a throwaway container is called from a shell script, if it works once, I'll keep using it, but I won't use it to run a Python server which also makes use of Matplotlib and other big dependencies.