Talip7/scikit-learn-issues-multilabel huggingface dataset:
inverse_transform of SimpleImputer with empty features changes order of columns

### Describe the bug

When one uses a SimpleImputer with `keep_empty_features=False` and `add_indicator=True`, then if a column has only missing values during fit, but has values during transform, then the inverse transform will shift all columns to the right of that column one to the left. 

(Note that I found this while experimenting and is not something that we rely on being fixed)

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.impute import SimpleImputer

X1 = np.array(
    [
        [np.nan, 2.0, 3.0],
        [np.nan, 2.0, 3.0],
    ]
)

X2 = np.array(
    [
        [1.0, 2.0, 3.0],
        [1.0, 2.0, 3.0],
    ]
)

imputer = SimpleImputer(add_indicator=True)
imputer.fit(X1)
print(imputer.inverse_transform(imputer.transform(X2)))
```

### Expected Results

I think the best way to go is to fill the missing columns with the value from `missing_values`.

```python
[[nan 2. 3.]
 [nan 2. 3.]]
```

### Actual Results

```python
[[2. 3. 0.]
 [2. 3. 0.]]
```

### Versions

```shell
System:
    python: 3.11.4
executable: [redacted]
   machine: macOS-13.4.1-arm64-arm-64bit

Python dependencies:
      sklearn: 1.3.0
          pip: 23.2
   setuptools: 68.0.0
        numpy: 1.25.1
        scipy: 1.11.1
       Cython: None
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.0
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: [redacted]
        version: 0.3.23
threading_layer: openmp
   architecture: VORTEX

       user_api: openmp
   internal_api: openmp
    num_threads: 12
         prefix: libomp
       filepath: [redacted]
        version: None
```

COMMENT:
Two bugs highlighted here:

1. The indicator column (the final column of zeros) ought to be removed after the inverse
2. The inverse transform knows what it removes, and so should be able to "put it back". Ideally, the inverse should behave as an actual inverse and fully undo the initial transformation.

PRs are welcome for both.

Labels: Bug, help wanted
inverse_transform of SimpleImputer with empty features changes order of columns

### Describe the bug

When one uses a SimpleImputer with `keep_empty_features=False` and `add_indicator=True`, then if a column has only missing values during fit, but has values during transform, then the inverse transform will shift all columns to the right of that column one to the left. 

(Note that I found this while experimenting and is not something that we rely on being fixed)

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.impute import SimpleImputer

X1 = np.array(
    [
        [np.nan, 2.0, 3.0],
        [np.nan, 2.0, 3.0],
    ]
)

X2 = np.array(
    [
        [1.0, 2.0, 3.0],
        [1.0, 2.0, 3.0],
    ]
)

imputer = SimpleImputer(add_indicator=True)
imputer.fit(X1)
print(imputer.inverse_transform(imputer.transform(X2)))
```

### Expected Results

I think the best way to go is to fill the missing columns with the value from `missing_values`.

```python
[[nan 2. 3.]
 [nan 2. 3.]]
```

### Actual Results

```python
[[2. 3. 0.]
 [2. 3. 0.]]
```

### Versions

```shell
System:
    python: 3.11.4
executable: [redacted]
   machine: macOS-13.4.1-arm64-arm-64bit

Python dependencies:
      sklearn: 1.3.0
          pip: 23.2
   setuptools: 68.0.0
        numpy: 1.25.1
        scipy: 1.11.1
       Cython: None
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.0
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: [redacted]
        version: 0.3.23
threading_layer: openmp
   architecture: VORTEX

       user_api: openmp
   internal_api: openmp
    num_threads: 12
         prefix: libomp
       filepath: [redacted]
        version: None
```

COMMENT:
Can I work on this issue ? I think I can solve this issue.

Labels: Bug, help wanted
inverse_transform of SimpleImputer with empty features changes order of columns

### Describe the bug

When one uses a SimpleImputer with `keep_empty_features=False` and `add_indicator=True`, then if a column has only missing values during fit, but has values during transform, then the inverse transform will shift all columns to the right of that column one to the left. 

(Note that I found this while experimenting and is not something that we rely on being fixed)

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.impute import SimpleImputer

X1 = np.array(
    [
        [np.nan, 2.0, 3.0],
        [np.nan, 2.0, 3.0],
    ]
)

X2 = np.array(
    [
        [1.0, 2.0, 3.0],
        [1.0, 2.0, 3.0],
    ]
)

imputer = SimpleImputer(add_indicator=True)
imputer.fit(X1)
print(imputer.inverse_transform(imputer.transform(X2)))
```

### Expected Results

I think the best way to go is to fill the missing columns with the value from `missing_values`.

```python
[[nan 2. 3.]
 [nan 2. 3.]]
```

### Actual Results

```python
[[2. 3. 0.]
 [2. 3. 0.]]
```

### Versions

```shell
System:
    python: 3.11.4
executable: [redacted]
   machine: macOS-13.4.1-arm64-arm-64bit

Python dependencies:
      sklearn: 1.3.0
          pip: 23.2
   setuptools: 68.0.0
        numpy: 1.25.1
        scipy: 1.11.1
       Cython: None
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.0
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: [redacted]
        version: 0.3.23
threading_layer: openmp
   architecture: VORTEX

       user_api: openmp
   internal_api: openmp
    num_threads: 12
         prefix: libomp
       filepath: [redacted]
        version: None
```

COMMENT:
> Can I work on this issue ? I think I can solve this issue.

Sure, we'd appreciate the help! Just keep in mind that there are two bugs which ought to be handled in two, _separate_ PRs. The first is probably easier.

Labels: Bug, help wanted
inverse_transform of SimpleImputer with empty features changes order of columns

### Describe the bug

When one uses a SimpleImputer with `keep_empty_features=False` and `add_indicator=True`, then if a column has only missing values during fit, but has values during transform, then the inverse transform will shift all columns to the right of that column one to the left. 

(Note that I found this while experimenting and is not something that we rely on being fixed)

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.impute import SimpleImputer

X1 = np.array(
    [
        [np.nan, 2.0, 3.0],
        [np.nan, 2.0, 3.0],
    ]
)

X2 = np.array(
    [
        [1.0, 2.0, 3.0],
        [1.0, 2.0, 3.0],
    ]
)

imputer = SimpleImputer(add_indicator=True)
imputer.fit(X1)
print(imputer.inverse_transform(imputer.transform(X2)))
```

### Expected Results

I think the best way to go is to fill the missing columns with the value from `missing_values`.

```python
[[nan 2. 3.]
 [nan 2. 3.]]
```

### Actual Results

```python
[[2. 3. 0.]
 [2. 3. 0.]]
```

### Versions

```shell
System:
    python: 3.11.4
executable: [redacted]
   machine: macOS-13.4.1-arm64-arm-64bit

Python dependencies:
      sklearn: 1.3.0
          pip: 23.2
   setuptools: 68.0.0
        numpy: 1.25.1
        scipy: 1.11.1
       Cython: None
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.0
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: [redacted]
        version: 0.3.23
threading_layer: openmp
   architecture: VORTEX

       user_api: openmp
   internal_api: openmp
    num_threads: 12
         prefix: libomp
       filepath: [redacted]
        version: None
```

COMMENT:
Since the help wanted tag is here, I am assuming no one is working on this. I would take this up. 

@lorentzenchr @Micky774

Labels: Bug, help wanted
inverse_transform of SimpleImputer with empty features changes order of columns

### Describe the bug

When one uses a SimpleImputer with `keep_empty_features=False` and `add_indicator=True`, then if a column has only missing values during fit, but has values during transform, then the inverse transform will shift all columns to the right of that column one to the left. 

(Note that I found this while experimenting and is not something that we rely on being fixed)

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.impute import SimpleImputer

X1 = np.array(
    [
        [np.nan, 2.0, 3.0],
        [np.nan, 2.0, 3.0],
    ]
)

X2 = np.array(
    [
        [1.0, 2.0, 3.0],
        [1.0, 2.0, 3.0],
    ]
)

imputer = SimpleImputer(add_indicator=True)
imputer.fit(X1)
print(imputer.inverse_transform(imputer.transform(X2)))
```

### Expected Results

I think the best way to go is to fill the missing columns with the value from `missing_values`.

```python
[[nan 2. 3.]
 [nan 2. 3.]]
```

### Actual Results

```python
[[2. 3. 0.]
 [2. 3. 0.]]
```

### Versions

```shell
System:
    python: 3.11.4
executable: [redacted]
   machine: macOS-13.4.1-arm64-arm-64bit

Python dependencies:
      sklearn: 1.3.0
          pip: 23.2
   setuptools: 68.0.0
        numpy: 1.25.1
        scipy: 1.11.1
       Cython: None
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.0
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: [redacted]
        version: 0.3.23
threading_layer: openmp
   architecture: VORTEX

       user_api: openmp
   internal_api: openmp
    num_threads: 12
         prefix: libomp
       filepath: [redacted]
        version: None
```

COMMENT:
@lorentzenchr @Micky774 I have a fix for the above issue but I feel in general the current architecture of simple imputer is such that if you fit on some data and transform other data then it is prone to many errors. 
I can think of few additional test cases where things would fail if we fit and transform in this manner. 

I feel when we are transforming, we should re-calculate the statistics [number of missing feature for example] again rather than using them from fit time. I am opening a sperate issue for the new failing test cases I can think of to highlight the bigger issue.

Labels: Bug, help wanted
Should we consider moving from legacy numpy `RandomState` to `Random.Generator`?

Numpy `RandomState` is now legacy ("This generator is considered frozen and will have no further improvement") and the [documentation](https://numpy.org/doc/stable/reference/random/legacy.html#legacy-random-generation) advises against using it:

> This class should only be used if it is essential to have randoms that are identical to what would have been produced by previous versions of NumPy.

However, it sounds like `RandomState` will always work:

>  It is guaranteed to produce the same values as the final point release of NumPy v1.16.

[NEP19](https://numpy.org/neps/nep-0019-rng-policy.html) also says 

>  All current usages of RandomState will continue to work in perpetuity, though some may be discouraged through documentation. 

[`numpy.random.Generator`](https://numpy.org/doc/stable/reference/random/generator.html#numpy.random.Generator) was introduced in [version 1.17](https://numpy.org/doc/stable/release/1.17.0-notes.html) (specifically [this PR](https://github.com/numpy/numpy/pull/13163)) - our min dep is higher than this.

I don't have enough knowledge to know in what way the new generator is better (except for performance) but just asking as it is advised to not use the old one.

(Edit: for context saw this while working on #26958)

COMMENT:
Closing as duplicate!

Labels: Needs Triage
Comment is confusing.

This is probably not very important, but the comment [here](https://github.com/scikit-learn/scikit-learn/blob/38a06e4be504f3971d109d6741b8b4c7192d7323/sklearn/tree/_tree.pyx#L1270) on line 1270 confused me a bit. I imagine it's redundant and can be removed?

COMMENT:
I don't think we want to remove it. It is informative. Without reading the code, it tells me that the following condition holds as well. The fact that we don't check it informs me that the way we build the tree makes it optional.

Labels: Needs Triage
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:
It seems that Alpine is quite unique: https://github.com/pypa/pip/issues/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.

Labels: New Feature
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:
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.

Labels: New Feature
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:
I think it makes sense to close this one. If I miss something, feel free to reopen.

Labels: New Feature
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:
Thank you for the replies. I as suggested switched to bitnami/minideb as a baseimage.

Labels: New Feature
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:
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](https://github.com/numpy/numpy/issues/20089) and a [discusion in the numpy mailing-list](https://mail.python.org/archives/list/numpy-discussion@python.org/thread/JHMJQ6LKFPDMOFRGGG7WTNM5Y55QXHGK/)

Labels: New Feature
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:
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 https://github.com/numpy/numpy/issues/20089#issuecomment-1414412193.

Projects that have musllinux wheels: numpy, scipy, matplotlib, pandas. numpy and scipy since around June 2023 ([numpy 1.25](https://pypi.org/project/numpy/1.25.0/#files) and [scipy 1.11](https://pypi.org/project/scipy/1.11.1/#files) 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).

Labels: New Feature