It seems that Alpine is quite unique: pypa/pip#9735

Can I build a wheel for my platform or use "scikit_learn-1.3.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64" somehow?

Usually, if you try to do pip install and the wheel is unavailable, then pip will try to build the wheel and install it on your platform. It will take then more time but it should work.

As far as I know none of the built wheels (what is the correct jargon: built wheel, binary wheel?) that you can upload to PyPI work on Alpine. The issue linked above has a good explanation of why Alpine can't use manylinux wheels (the ones we do upload).

I don't think there is anything here that scikit-learn can do. Should we close this issue?

On a personal note (maybe discussing the pros and cons of docker images is beyond the scope of this issue tracker): I stopped using Alpine as my base image for production deployments because it is too tedious (and slow) to have to build the various Python packages I use(d) that have compiled extensions. Instead I started using the minimal debian/ubuntu images. The main motivation for Alpine was to have small(er) images but once you are deploying several services that all use the same debian/ubuntu base image you can share the "cost" of the bigger base image across all of your services. It quickly amortises that cost and you spend less time on maintaining the builds.

I think it makes sense to close this one. If I miss something, feel free to reopen.

Thank you for the replies. I as suggested switched to bitnami/minideb as a baseimage.

FWIW it seems like numpy and scipy have muslinux wheels, see https://pypi.org/project/numpy/#files and https://pypi.org/project/scipy/#files, so it should be possible, although not that likely to be super high priority I would say ...

For reference, here is the numpy issue about musllinux wheels and a discusion in the numpy mailing-list

Re-opening since there seems to be some interest e.g. #28490 and Meson support makes it more likely that we can build musllinux wheels.

We should decide whether we want to support muslinux wheels or not. I think one good summary comment from the Numpy issue mentioned above is numpy/numpy#20089 (comment).

Projects that have musllinux wheels: numpy, scipy, matplotlib, pandas. numpy and scipy since around June 2023 (numpy 1.25 and scipy 1.11 were the first releases to have musllinux wheels).

Projects that do not have musllinux wheels: scikit-learn, scikit-image

FWIW, it seems like there are some unofficial scikit-learn musllinux wheels available https://github.com/alpine-wheels, with an associated PyPI index https://alpine-wheels.github.io/index/-/simple/ so I guess this is a reasonable work-around. Not sure how up-to-date this is supposed to be, for example they don't see yet to have 1.4.1.post1 (released February 15, time of writing February 21).

Replying to @betatim's comment #28490 (comment):

Looking at this, I'd vote for providing the wheels.

I am +1 too.

What are the downsides? More wheels being built, so more chances for something to go wrong? It might not be easy to stop providing them again? Are there hidden assumptions in scikit-learn's code regarding glibc (is that even a thing that is possible?)?

I guess more potential CI issues that can block/delay a release. numpy/numpy#20089 (comment) seems to indicate that there are less opportunity for weird behaviours though than on other more exotic CI builds.

[CI stability is a concern] but more so for nonstandard hardware than for something that runs on plain Linux x86-64 and aarch64 instances. So for Musl it should be pretty good compared to our other candidates for inclusion in our zoo of wheels.

Edit: another downside is that this may also open the door to other similar requests, for example musl aarch64 wheels numpy/numpy#24934 which may mean more maintenance and/or CirrusCI credit. numpy 1.26.2 has musl aarch64 wheels, scipy does not have them yet I think.

If Numpy and Scipy have been building wheels for a while I'd assume the process is pretty mature.

I would not call this a while, but Numpy and Scipy have been providing musllinux wheels since June 2023 roughly (numpy 1.25 and scipy 1.11 were the first releases to have musllinux wheels).

For the record this was discussed at yesterday's monthly dev meeting and for now the consensus seems to be that the extra maintenance effort and CI costs are not necessarily worth it.

Note that apparently only the base alpine image seems significantly smaller (-slim vs -alpine. The wheel files themselves have approximately the same size (manylinux vs musllinux). Here are the respective sizes of the base python images from the docker hub:

$ docker image ls python
REPOSITORY   TAG           IMAGE ID       CREATED       SIZE
python       3.12-alpine   80f904359cf6   2 weeks ago   56.5MB
python       3.12-slim     2b08f52dfa3f   2 weeks ago   156MB
python       latest        d8be44680b2e   2 weeks ago   1.02GB

Once you docker build a custom image with numpy in them:

$ cat tmp/dockerfiles/numpy-alpine/Dockerfile
FROM python:3.12-alpine

RUN pip install --no-cache-dir numpy
$ docker build -t numpy:3.12-alpine tmp/dockerfiles/numpy-alpine
[...]
$ cat tmp/dockerfiles/numpy-slim/Dockerfile
FROM python:3.12-slim

RUN pip install --no-cache-dir numpy
$ docker build -t numpy:3.12-slim tmp/dockerfiles/numpy-slim
[...]
$ docker image ls numpy
REPOSITORY   TAG           IMAGE ID       CREATED              SIZE
numpy        3.12-slim     3eee14b2c828   26 seconds ago       224MB
numpy        3.12-alpine   4d387d2212af   About a minute ago   122MB

So there is the fixed 100 MB offset of the base image. But then installing extra alpine packages over manylinux packages does not seem to save more than a few percents (taking the base image offset aside).

And as @betatim observed above it's quite likely that the base image can be cached and shared if your run several Python-based containerized apps on the same host.

EDIT: note that the maintainers might reconsider that decision (not to provide musllinux wheels on pypi.org) based on expressed user feedback e.g. next year.

EDIT 2: feel free to express your quick feedback as emojis on this comment, I promise I won't take it personally.

EDIT 3: if you have a specific workfload for which the 100 MB offset between the 2 base images is important and image caching does not help, feel free to post a comment with more details.

Just wanted to add that another consideration except size is that the -alpine base image (3.12.2 as an example) has a lot fewer vulnerabilities than -slim. Most of them come from the debian:12 image. At least that is another main reason why I tried to move to alpine (before realising I can't use scikit-learn in it).

In the past the vulnerability scan results were biased/not representative because of how debian labels issues and how this is different from other distros. This opinion comes from docker-library/python#708 (comment)

I've not kept myself up to date with these discussions as I've not been in the business of running services for a few years now, but I assume that debian hasn't changed their procedures that much in such a "short" time frame. So maybe something to follow up with before making a decision.

Many thanks for that piece of info!

I am closing this as "not planned", we can always reopen if the consensus changes compared to #27004 (comment).

First of all, thank you very much for your work in this project and your consideration of this

I am one of those that would greatly appreciate pre-built musl wheels, basically because

And as @betatim observed above it's quite likely that the base image can be cached and shared if your run several Python-based containerized apps on the same host.

does not work well with managed CI runners (e.g: the ones provided or bought from gitlab.com or github.com). I understand there would be ways to work around it, but that requires extra work for all of us downstream.

Just voicing here my opinion as feedback was requested. I can understand the maintenance upstream might not be appreciated.

EDIT: I am an Alpine regular contributor and maintain musl CI in a couple of projects. So if the concern is help debugging issues that might raise, I offer my help