Upload musllinux wheel to PyPI

### Describe the workflow you want to enable

I want to pip install scikit-learn==1.3.0 into a docker alpine 3.11 Installation, but it appears that here are no wheels available for that platform.

Pip shows my my platform tags as
```
  cp311-cp311-musllinux_1_2_x86_64
  cp311-cp311-musllinux_1_1_x86_64
  cp311-cp311-musllinux_1_0_x86_64
  cp311-cp311-linux_x86_64
  cp311-abi3-musllinux_1_2_x86_64
  cp311-abi3-musllinux_1_1_x86_64
  cp311-abi3-musllinux_1_0_x86_64
  cp311-abi3-linux_x86_64
  cp311-none-musllinux_1_2_x86_64
  cp311-none-musllinux_1_1_x86_64
  cp311-none-musllinux_1_0_x86_64
  cp311-none-linux_x86_64
```

Available wheels in pypy are
```
scikit_learn-1.3.0-cp311-cp311-win_amd64
scikit_learn-1.3.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64
scikit_learn-1.3.0-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64
scikit_learn-1.3.0-cp311-cp311-macosx_12_0_arm64.whl
scikit_learn-1.3.0-cp311-cp311-macosx_10_9_x86_64.whl
```



### Describe your proposed solution

I unfortunately dont understand enough about wheels, but 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?

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
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.

Labels: New Feature