Talip7/scikit-learn-issues-multilabel huggingface dataset:
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:
Replying to @betatim's comment https://github.com/scikit-learn/scikit-learn/pull/28490#issuecomment-1957001681:

> 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. https://github.com/numpy/numpy/issues/20089#issuecomment-1414412193 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 https://github.com/numpy/numpy/issues/24934 which may mean more maintenance and/or CirrusCI credit. [numpy 1.26.2](https://pypi.org/project/numpy/1.26.2/#files) 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](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).

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:
Just wanted to add that another consideration except size is that the `-alpine` base image ([3.12.2 as an example](https://hub.docker.com/layers/library/python/3.12.2-slim/images/sha256-f0c6bc1ab7b1ab270bbb612a31a67a7938d6171183ddce9121f04984ab3df44e?context=explore)) has a lot fewer vulnerabilities than [`-slim`](https://hub.docker.com/layers/library/python/3.12.2-slim/images/sha256-f0c6bc1ab7b1ab270bbb612a31a67a7938d6171183ddce9121f04984ab3df44e?context=explore). 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).

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:
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 https://github.com/docker-library/python/issues/708#issuecomment-1295196071

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.

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:
Many thanks for that piece of info!

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 am closing this as "not planned", we can always reopen if the consensus changes compared to https://github.com/scikit-learn/scikit-learn/issues/27004#issuecomment-1966926217.

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

Labels: New Feature
make cross_val_predict use cross_validate

Right now `cross_val_score` is a wrapper for `cross_validate`, but `cross_val_predict` has its own implementation.

We could make it also a wrapper around `cross_validate`, but for that to happen, we need to make `cross_validate` also return predictions. For that, we would also need to be able to pass `y_pred, y_true` to scorers instead of passing the estimator, which would also remove the need to cache in `_MultimetricScorer` and make things quite a bit cleaner.

cc @glemaitre 

xref: https://github.com/scikit-learn/scikit-learn/pull/26896#pullrequestreview-1560866760

COMMENT:
Hi, @adrinjalali, can I work on this? How should I proceed further?

Labels: Moderate, API
make cross_val_predict use cross_validate

Right now `cross_val_score` is a wrapper for `cross_validate`, but `cross_val_predict` has its own implementation.

We could make it also a wrapper around `cross_validate`, but for that to happen, we need to make `cross_validate` also return predictions. For that, we would also need to be able to pass `y_pred, y_true` to scorers instead of passing the estimator, which would also remove the need to cache in `_MultimetricScorer` and make things quite a bit cleaner.

cc @glemaitre 

xref: https://github.com/scikit-learn/scikit-learn/pull/26896#pullrequestreview-1560866760

COMMENT:
@navaneethkulal8 as you can see this issue is labeled as "moderate" and best left to someone who's quite familiar with the code base. And easier issue might be better for you to start on.

Labels: Moderate, API
make cross_val_predict use cross_validate

Right now `cross_val_score` is a wrapper for `cross_validate`, but `cross_val_predict` has its own implementation.

We could make it also a wrapper around `cross_validate`, but for that to happen, we need to make `cross_validate` also return predictions. For that, we would also need to be able to pass `y_pred, y_true` to scorers instead of passing the estimator, which would also remove the need to cache in `_MultimetricScorer` and make things quite a bit cleaner.

cc @glemaitre 

xref: https://github.com/scikit-learn/scikit-learn/pull/26896#pullrequestreview-1560866760

COMMENT:
Thanks for the feedback, @adrinjalali

Labels: Moderate, API
make cross_val_predict use cross_validate

Right now `cross_val_score` is a wrapper for `cross_validate`, but `cross_val_predict` has its own implementation.

We could make it also a wrapper around `cross_validate`, but for that to happen, we need to make `cross_validate` also return predictions. For that, we would also need to be able to pass `y_pred, y_true` to scorers instead of passing the estimator, which would also remove the need to cache in `_MultimetricScorer` and make things quite a bit cleaner.

cc @glemaitre 

xref: https://github.com/scikit-learn/scikit-learn/pull/26896#pullrequestreview-1560866760

COMMENT:
Hi @adrinjalali, I would like to work on this issue.

Labels: Moderate, API
make cross_val_predict use cross_validate

Right now `cross_val_score` is a wrapper for `cross_validate`, but `cross_val_predict` has its own implementation.

We could make it also a wrapper around `cross_validate`, but for that to happen, we need to make `cross_validate` also return predictions. For that, we would also need to be able to pass `y_pred, y_true` to scorers instead of passing the estimator, which would also remove the need to cache in `_MultimetricScorer` and make things quite a bit cleaner.

cc @glemaitre 

xref: https://github.com/scikit-learn/scikit-learn/pull/26896#pullrequestreview-1560866760

COMMENT:
> We could make it also a wrapper around `cross_validate`, but for that to happen, we need to make `cross_validate` also return predictions. For that, we would also need to be able to pass `y_pred, y_true` to scorers instead of passing the estimator, which would also remove the need to cache in `_MultimetricScorer` and make things quite a bit cleaner.

I am wondering why we need to pass `y_pred, y_true` to scorers instead of passing the estimator. From my understanding, if `cross_val_predict` were to be a wrapper around `cross_validate`, then once we obtain the predictions, we can use these values instead of recomputing them during the scoring process. What other reasons may I be missing?

Labels: Moderate, API
make cross_val_predict use cross_validate

Right now `cross_val_score` is a wrapper for `cross_validate`, but `cross_val_predict` has its own implementation.

We could make it also a wrapper around `cross_validate`, but for that to happen, we need to make `cross_validate` also return predictions. For that, we would also need to be able to pass `y_pred, y_true` to scorers instead of passing the estimator, which would also remove the need to cache in `_MultimetricScorer` and make things quite a bit cleaner.

cc @glemaitre 

xref: https://github.com/scikit-learn/scikit-learn/pull/26896#pullrequestreview-1560866760

COMMENT:
@adrinjalali  
I will work on this ..

Labels: Moderate, API
make cross_val_predict use cross_validate

Right now `cross_val_score` is a wrapper for `cross_validate`, but `cross_val_predict` has its own implementation.

We could make it also a wrapper around `cross_validate`, but for that to happen, we need to make `cross_validate` also return predictions. For that, we would also need to be able to pass `y_pred, y_true` to scorers instead of passing the estimator, which would also remove the need to cache in `_MultimetricScorer` and make things quite a bit cleaner.

cc @glemaitre 

xref: https://github.com/scikit-learn/scikit-learn/pull/26896#pullrequestreview-1560866760

COMMENT:
@sadepu1915 This is not an easy one to start with, and requires quite a bit of familiarity with the codebase.

Labels: Moderate, API
make cross_val_predict use cross_validate

Right now `cross_val_score` is a wrapper for `cross_validate`, but `cross_val_predict` has its own implementation.

We could make it also a wrapper around `cross_validate`, but for that to happen, we need to make `cross_validate` also return predictions. For that, we would also need to be able to pass `y_pred, y_true` to scorers instead of passing the estimator, which would also remove the need to cache in `_MultimetricScorer` and make things quite a bit cleaner.

cc @glemaitre 

xref: https://github.com/scikit-learn/scikit-learn/pull/26896#pullrequestreview-1560866760

COMMENT:
@adrinjalali 
sure , I am feeling I have decent understanding of code :-) I might be wrong ... let me try 

you can pitch me idea or any approach plan on how to attack on this

Labels: Moderate, API
make cross_val_predict use cross_validate

Right now `cross_val_score` is a wrapper for `cross_validate`, but `cross_val_predict` has its own implementation.

We could make it also a wrapper around `cross_validate`, but for that to happen, we need to make `cross_validate` also return predictions. For that, we would also need to be able to pass `y_pred, y_true` to scorers instead of passing the estimator, which would also remove the need to cache in `_MultimetricScorer` and make things quite a bit cleaner.

cc @glemaitre 

xref: https://github.com/scikit-learn/scikit-learn/pull/26896#pullrequestreview-1560866760

COMMENT:
@glemaitre had some ideas regarding the scorer API which would accept `y_true, y_pred` I think.

Labels: Moderate, API
LassoCV fails when I pass weights.

### Describe the bug

LassoCV throws the following error when I pass weights in .fit

ValueError: Input contains NaN.

The X, y as well as the weights do not contain any NaN values.

### Steps/Code to Reproduce

```
estimator_params = {'cv': 25, 'tol': 0.0001, 'max_iter': 500, 'alphas': [0.001, 0.003, 0.005, 0.007, 0.009, 0.0001, 0.0005], 'n_jobs': -1, 'precompute': True, 'selection': 'random', 'fit_intercept': True, 'positive': False, 'random_state': 2020}
estimator = LassoCV(**estimator_params)
estimator.fit( X, y, wts)
```
[wts.txt](https://github.com/scikit-learn/scikit-learn/files/12243195/wts.txt)
[X.txt](https://github.com/scikit-learn/scikit-learn/files/12243196/X.txt)
[y.txt](https://github.com/scikit-learn/scikit-learn/files/12243197/y.txt)


### Expected Results

No error is thrown.

### Actual Results

ValueError: Input contains NaN.



### Versions

```shell
System:
    python: 3.8.10 (default, May 26 2023, 14:05:08)  [GCC 9.4.0]
executable: /local_disk0/pythonVirtualEnvDirs/virtualEnv-cfd639f7-075b-4940-b5a6-959b505608aa/bin/python
   machine: Linux-5.15.0-1041-azure-x86_64-with-glibc2.29

Python dependencies:
      sklearn: 1.3.0
          pip: 21.0.1
   setuptools: 52.0.0
        numpy: 1.22.4
        scipy: 1.6.2
       Cython: 0.29.23
       pandas: 1.2.4
   matplotlib: 3.4.2
       joblib: 1.3.1
threadpoolctl: 2.1.0

Built with OpenMP: True
Exception ignored on calling ctypes callback function: <function _ThreadpoolInfo._find_modules_with_dl_iterate_phdr.<locals>.match_module_callback at 0x7f6a96aa58b0>
Traceback (most recent call last):
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 400, in match_module_callback
    self._make_module_from_path(filepath)
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 515, in _make_module_from_path
    module = module_class(filepath, prefix, user_api, internal_api)
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 606, in __init__
    self.version = self.get_version()
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 646, in get_version
    config = get_config().split()
AttributeError: 'NoneType' object has no attribute 'split'

threadpoolctl info:
       filepath: /databricks/python3/lib/python3.8/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
         prefix: libgomp
       user_api: openmp
   internal_api: openmp
        version: None
    num_threads: 4

       filepath: /databricks/python3/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-085ca80a.3.9.so
         prefix: libopenblas
       user_api: blas
   internal_api: openblas
        version: 0.3.9
    num_threads: 4
threading_layer: pthreads
```

COMMENT:
Cannot reproduce since the data attached of `X` is just a print representation.

Labels: Needs Reproducible Code