Talip7/scikit-learn-issues-multilabel huggingface dataset:
⚠️ CI failed on Linux_Nightly.pylatest_pip_scipy_dev (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Linux_Nightly.pylatest_pip_scipy_dev](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70432&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf)** (Sep 22, 2024)
- test_lbfgs_solver_consistency[0.001]
- test_lbfgs_solver_consistency[0.01]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-None-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_matrix-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_array-False]
- test_converged_to_local_maximum[kernel2]
- test_multinomial_logistic_regression_string_inputs
- test_logistic_regression_multinomial
- test_warm_start_effectiveness

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70436&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf) on Sep 23, 2024

Labels: Needs Triage
⚠️ CI failed on Linux_Nightly.pylatest_pip_scipy_dev (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Linux_Nightly.pylatest_pip_scipy_dev](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70432&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf)** (Sep 22, 2024)
- test_lbfgs_solver_consistency[0.001]
- test_lbfgs_solver_consistency[0.01]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-None-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_matrix-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_array-False]
- test_converged_to_local_maximum[kernel2]
- test_multinomial_logistic_regression_string_inputs
- test_logistic_regression_multinomial
- test_warm_start_effectiveness

COMMENT:
Good bot!

Thank you @lesteve for the heads up and apologies for the inconvenience. Some bugs only come out with large problems unfortunately.

Labels: Needs Triage
⚠️ CI failed on Linux_Nightly.pylatest_pip_scipy_dev (last failure: Sep 22, 2024) ⚠️

**CI is still failing on [Linux_Nightly.pylatest_pip_scipy_dev](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70432&view=logs&j=dfe99b15-50db-5d7b-b1e9-4105c42527cf)** (Sep 22, 2024)
- test_lbfgs_solver_consistency[0.001]
- test_lbfgs_solver_consistency[0.01]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-None-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_matrix-False]
- test_ridge_sample_weight_consistency[55-lbfgs-wide-csr_array-False]
- test_converged_to_local_maximum[kernel2]
- test_multinomial_logistic_regression_string_inputs
- test_logistic_regression_multinomial
- test_warm_start_effectiveness

COMMENT:
Thanks for the fix! CI is happy, let' close this one.

Labels: Needs Triage
`cross_validate` accepts `sample_weight` in fitted estimator, but should raise or warn

### Describe the bug

When we pass a fitted estimator into `cross_validate` it will fit this estimator again on the given train-validation splits.
However, users can pass `sample_weight` to the fitted estimator without being warned that it is not taken into account.

This might also be the case for other splitters. I have not tested.

### Steps/Code to Reproduce

```python
from sklearn.linear_model import Ridge
from sklearn.model_selection import cross_validate
import numpy as np

rng = np.random.RandomState(42)
X = rng.rand(200, 5)
y = rng.randint(0, 2, size=X.shape[0])
sample_weight = rng.rand(X.shape[0])

ridge = Ridge()
scores = cross_validate(ridge, X, y, return_train_score=True) 

ridge = Ridge().fit(X,y, sample_weight=sample_weight)
scores_with_sample_weight = cross_validate(ridge, X, y, return_train_score=True)
```

### Expected Results

The scores with or without `sample_weight` passed to the estimator's fit method are the same. Passing `sample_weight` has no effect.
Thus, the user should be warned about this fact or the estimator should raise.
The message can maybe contain a hint to use the metadata routing API.

### Actual Results

nothing happens

### Versions

```shell
System:
    python: 3.12.2 (main, Apr 18 2024, 11:14:27) [GCC 13.2.1 20230801]
executable: /home/stefanie/.pyenv/versions/3.12.2/envs/scikit-learn_dev/bin/python
   machine: Linux-6.10.7-arch1-1-x86_64-with-glibc2.40

Python dependencies:
      sklearn: 1.6.dev0
          pip: 24.2
   setuptools: 69.5.1
        numpy: 2.0.1
        scipy: 1.14.0
       Cython: 3.0.10
       pandas: 2.2.2
   matplotlib: 3.9.1
       joblib: 1.4.0
threadpoolctl: 3.4.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 14
         prefix: libgomp
       filepath: /usr/lib/libgomp.so.1.0.0
        version: None
```

COMMENT:
I don't think that's something we want / can reliably fix. When the user doesn't pass `sample_weight` to `cross_validate`, they shouldn't expect weights to be taken into account. Fixing this would require keeping track of what was passed to `fit`, and I don't think we should be doing that.

Labels: Bug, Needs Triage
`cross_validate` accepts `sample_weight` in fitted estimator, but should raise or warn

### Describe the bug

When we pass a fitted estimator into `cross_validate` it will fit this estimator again on the given train-validation splits.
However, users can pass `sample_weight` to the fitted estimator without being warned that it is not taken into account.

This might also be the case for other splitters. I have not tested.

### Steps/Code to Reproduce

```python
from sklearn.linear_model import Ridge
from sklearn.model_selection import cross_validate
import numpy as np

rng = np.random.RandomState(42)
X = rng.rand(200, 5)
y = rng.randint(0, 2, size=X.shape[0])
sample_weight = rng.rand(X.shape[0])

ridge = Ridge()
scores = cross_validate(ridge, X, y, return_train_score=True) 

ridge = Ridge().fit(X,y, sample_weight=sample_weight)
scores_with_sample_weight = cross_validate(ridge, X, y, return_train_score=True)
```

### Expected Results

The scores with or without `sample_weight` passed to the estimator's fit method are the same. Passing `sample_weight` has no effect.
Thus, the user should be warned about this fact or the estimator should raise.
The message can maybe contain a hint to use the metadata routing API.

### Actual Results

nothing happens

### Versions

```shell
System:
    python: 3.12.2 (main, Apr 18 2024, 11:14:27) [GCC 13.2.1 20230801]
executable: /home/stefanie/.pyenv/versions/3.12.2/envs/scikit-learn_dev/bin/python
   machine: Linux-6.10.7-arch1-1-x86_64-with-glibc2.40

Python dependencies:
      sklearn: 1.6.dev0
          pip: 24.2
   setuptools: 69.5.1
        numpy: 2.0.1
        scipy: 1.14.0
       Cython: 3.0.10
       pandas: 2.2.2
   matplotlib: 3.9.1
       joblib: 1.4.0
threadpoolctl: 3.4.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 14
         prefix: libgomp
       filepath: /usr/lib/libgomp.so.1.0.0
        version: None
```

COMMENT:
> Fixing this would require keeping track of what was passed to fit, and I don't think we should be doing that.

I also think we shouldn't try to fix that. We have metadata routing API for this purpose.
My suggestion was to raise or warn.

Labels: Bug, Needs Triage
`cross_validate` accepts `sample_weight` in fitted estimator, but should raise or warn

### Describe the bug

When we pass a fitted estimator into `cross_validate` it will fit this estimator again on the given train-validation splits.
However, users can pass `sample_weight` to the fitted estimator without being warned that it is not taken into account.

This might also be the case for other splitters. I have not tested.

### Steps/Code to Reproduce

```python
from sklearn.linear_model import Ridge
from sklearn.model_selection import cross_validate
import numpy as np

rng = np.random.RandomState(42)
X = rng.rand(200, 5)
y = rng.randint(0, 2, size=X.shape[0])
sample_weight = rng.rand(X.shape[0])

ridge = Ridge()
scores = cross_validate(ridge, X, y, return_train_score=True) 

ridge = Ridge().fit(X,y, sample_weight=sample_weight)
scores_with_sample_weight = cross_validate(ridge, X, y, return_train_score=True)
```

### Expected Results

The scores with or without `sample_weight` passed to the estimator's fit method are the same. Passing `sample_weight` has no effect.
Thus, the user should be warned about this fact or the estimator should raise.
The message can maybe contain a hint to use the metadata routing API.

### Actual Results

nothing happens

### Versions

```shell
System:
    python: 3.12.2 (main, Apr 18 2024, 11:14:27) [GCC 13.2.1 20230801]
executable: /home/stefanie/.pyenv/versions/3.12.2/envs/scikit-learn_dev/bin/python
   machine: Linux-6.10.7-arch1-1-x86_64-with-glibc2.40

Python dependencies:
      sklearn: 1.6.dev0
          pip: 24.2
   setuptools: 69.5.1
        numpy: 2.0.1
        scipy: 1.14.0
       Cython: 3.0.10
       pandas: 2.2.2
   matplotlib: 3.9.1
       joblib: 1.4.0
threadpoolctl: 3.4.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 14
         prefix: libgomp
       filepath: /usr/lib/libgomp.so.1.0.0
        version: None
```

COMMENT:
In order to raise or warn, we need to check whether `sample_weight` was passed to the fitted estimator given to `cross_validate`. Doing this check requires storing that information in all estimators.

Labels: Bug, Needs Triage
`cross_validate` accepts `sample_weight` in fitted estimator, but should raise or warn

### Describe the bug

When we pass a fitted estimator into `cross_validate` it will fit this estimator again on the given train-validation splits.
However, users can pass `sample_weight` to the fitted estimator without being warned that it is not taken into account.

This might also be the case for other splitters. I have not tested.

### Steps/Code to Reproduce

```python
from sklearn.linear_model import Ridge
from sklearn.model_selection import cross_validate
import numpy as np

rng = np.random.RandomState(42)
X = rng.rand(200, 5)
y = rng.randint(0, 2, size=X.shape[0])
sample_weight = rng.rand(X.shape[0])

ridge = Ridge()
scores = cross_validate(ridge, X, y, return_train_score=True) 

ridge = Ridge().fit(X,y, sample_weight=sample_weight)
scores_with_sample_weight = cross_validate(ridge, X, y, return_train_score=True)
```

### Expected Results

The scores with or without `sample_weight` passed to the estimator's fit method are the same. Passing `sample_weight` has no effect.
Thus, the user should be warned about this fact or the estimator should raise.
The message can maybe contain a hint to use the metadata routing API.

### Actual Results

nothing happens

### Versions

```shell
System:
    python: 3.12.2 (main, Apr 18 2024, 11:14:27) [GCC 13.2.1 20230801]
executable: /home/stefanie/.pyenv/versions/3.12.2/envs/scikit-learn_dev/bin/python
   machine: Linux-6.10.7-arch1-1-x86_64-with-glibc2.40

Python dependencies:
      sklearn: 1.6.dev0
          pip: 24.2
   setuptools: 69.5.1
        numpy: 2.0.1
        scipy: 1.14.0
       Cython: 3.0.10
       pandas: 2.2.2
   matplotlib: 3.9.1
       joblib: 1.4.0
threadpoolctl: 3.4.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 14
         prefix: libgomp
       filepath: /usr/lib/libgomp.so.1.0.0
        version: None
```

COMMENT:
> In order to raise or warn, we need to check whether sample_weight was passed to the fitted estimator given to cross_validate. Doing this check requires storing that information in all estimators.

Yea, I was assuming it was a probably an extensive fix. Now you put it very clearly what would needed to be done.
I still don't think it's an ideal situation, but I also see that with metadata routing becoming the default, this problem will vanish.

Labels: Bug, Needs Triage
Adding scikit-learn to the pydata-sphinx-theme gallery of sites

As described in the title, I wonder if we want to add scikit-learn to the list of pydata-sphinx-theme gallery of sites: https://pydata-sphinx-theme.readthedocs.io/en/stable/examples/gallery.html. If we do I can ask pydata-sphinx-theme about it.

COMMENT:
+1 for this suggestion.

Labels: Documentation, RFC
Adding scikit-learn to the pydata-sphinx-theme gallery of sites

As described in the title, I wonder if we want to add scikit-learn to the list of pydata-sphinx-theme gallery of sites: https://pydata-sphinx-theme.readthedocs.io/en/stable/examples/gallery.html. If we do I can ask pydata-sphinx-theme about it.

COMMENT:
It's in the features sites list now! https://pydata-sphinx-theme.readthedocs.io/en/latest/examples/gallery.html#featured-projects

![image](https://github.com/user-attachments/assets/aed15056-2d44-48c4-8426-9ae87ae7803d)

Labels: Documentation, RFC
Adding scikit-learn to the pydata-sphinx-theme gallery of sites

As described in the title, I wonder if we want to add scikit-learn to the list of pydata-sphinx-theme gallery of sites: https://pydata-sphinx-theme.readthedocs.io/en/stable/examples/gallery.html. If we do I can ask pydata-sphinx-theme about it.

COMMENT:
nice Thanks @Charlie-XIAO

Labels: Documentation, RFC
Add float as acceptable input for n_jobs

### Describe the workflow you want to enable

Float may be used as possible input for n_jobs. That is, allowing selection of set percentage of the machine's CPU core count. 

### Describe your proposed solution

When n_jobs is a float (in the range `(0.0, 1.0]`), the number of CPU cores can be checked using the STL or scikit-learn dependencies, with `os.cpu_count()`, `multiprocessing.cpu_count()`, `joblib.cpu_count()`, etc. and `max(round(cpu_count*n_jobs), 1)` can be set as the value of self.n_jobs.

COMMENT:
This would be a feature request for joblib rather than scikit-learn because scikit-learn exposes the `n_jobs` parameter of the underlying `joblib` library. However I am not sure we want to do this because users might not realize that `n_jobs=1.0` would mean the same thing as `n_jobs=-1` when they would have expected `n_jobs=1.0` to mean the same as `n_jobs=1` (sequential execution).

EDIT: I am curious to know what other people thing (both users and maintainers).

Labels: New Feature, Needs Decision
Add float as acceptable input for n_jobs

### Describe the workflow you want to enable

Float may be used as possible input for n_jobs. That is, allowing selection of set percentage of the machine's CPU core count. 

### Describe your proposed solution

When n_jobs is a float (in the range `(0.0, 1.0]`), the number of CPU cores can be checked using the STL or scikit-learn dependencies, with `os.cpu_count()`, `multiprocessing.cpu_count()`, `joblib.cpu_count()`, etc. and `max(round(cpu_count*n_jobs), 1)` can be set as the value of self.n_jobs.

COMMENT:
Having a different behavior between `1` and `1.0` is a big design flaw imo. It could be a string with a explicit percentage (e.g. `n_jobs="50%"`) instead but I usually don't like this pattern either :)

Regarding the request for fraction of total number of cpu cores, I can understand the need. And given that counting the actual number of cores can be tricky, especially in containers, I think it makes sense to let joblib handle that. Otherwise, doing it manually can lead to confusing behavior.

Labels: New Feature, Needs Decision
Add float as acceptable input for n_jobs

### Describe the workflow you want to enable

Float may be used as possible input for n_jobs. That is, allowing selection of set percentage of the machine's CPU core count. 

### Describe your proposed solution

When n_jobs is a float (in the range `(0.0, 1.0]`), the number of CPU cores can be checked using the STL or scikit-learn dependencies, with `os.cpu_count()`, `multiprocessing.cpu_count()`, `joblib.cpu_count()`, etc. and `max(round(cpu_count*n_jobs), 1)` can be set as the value of self.n_jobs.

COMMENT:
Then n_jobs can be a float in the range `(0.0, 1.0)`, although some similar parameters that accept both float and int inputs allow `1.0` as a float input, i. e. [max_samples, for example in RandomForestClassifier](https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.RandomForestClassifier.html#sklearn.ensemble.RandomForestClassifier). So I think whether to allow `1.0` as an input for using 100% of an amount should be universal.

Labels: New Feature, Needs Decision
Add float as acceptable input for n_jobs

### Describe the workflow you want to enable

Float may be used as possible input for n_jobs. That is, allowing selection of set percentage of the machine's CPU core count. 

### Describe your proposed solution

When n_jobs is a float (in the range `(0.0, 1.0]`), the number of CPU cores can be checked using the STL or scikit-learn dependencies, with `os.cpu_count()`, `multiprocessing.cpu_count()`, `joblib.cpu_count()`, etc. and `max(round(cpu_count*n_jobs), 1)` can be set as the value of self.n_jobs.

COMMENT:
> although some similar parameters that accept both float and int inputs allow 1.0 as a float input, i. e. [max_samples, for example in RandomForestClassifier](https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.RandomForestClassifier.html#sklearn.ensemble.RandomForestClassifier).

Yes there are some occurrences of that in scikit-learn but it doesn't mean we're happy with it :smile:. I would personally be in favor of removing this pattern everywhere. And for new additions, it doesn't prevent us from trying to avoid making the same mistakes again.

Labels: New Feature, Needs Decision
Add float as acceptable input for n_jobs

### Describe the workflow you want to enable

Float may be used as possible input for n_jobs. That is, allowing selection of set percentage of the machine's CPU core count. 

### Describe your proposed solution

When n_jobs is a float (in the range `(0.0, 1.0]`), the number of CPU cores can be checked using the STL or scikit-learn dependencies, with `os.cpu_count()`, `multiprocessing.cpu_count()`, `joblib.cpu_count()`, etc. and `max(round(cpu_count*n_jobs), 1)` can be set as the value of self.n_jobs.

COMMENT:
> EDIT: I am curious to know what other people thing (both users and maintainers).

clear -1 from me.

If as a user you want to control the number of jobs in term of fraction of total cores, you can write 1-2 more lines as mentioned in the top post, i.e. something like this:
```py
# pick the variation you want here including only_physical_cores=True/False
cpu_count = joblib.cpu_count()
search = GridSearchCV(..., n_jobs=round(0.75*cpu_count))
```

Labels: New Feature, Needs Decision
Add float as acceptable input for n_jobs

### Describe the workflow you want to enable

Float may be used as possible input for n_jobs. That is, allowing selection of set percentage of the machine's CPU core count. 

### Describe your proposed solution

When n_jobs is a float (in the range `(0.0, 1.0]`), the number of CPU cores can be checked using the STL or scikit-learn dependencies, with `os.cpu_count()`, `multiprocessing.cpu_count()`, `joblib.cpu_count()`, etc. and `max(round(cpu_count*n_jobs), 1)` can be set as the value of self.n_jobs.

COMMENT:
Yeah, also -1 from me, the fix for the actual usecase is trivial as @lesteve points out.

Labels: New Feature, Needs Decision
⚠️ CI failed on Wheel builder (last failure: Sep 13, 2024) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/10842683629)** (Sep 13, 2024)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/10859271523) on Sep 14, 2024

Labels: Build / CI
⚠️ CI failed on Linux_free_threaded.pylatest_pip_free_threaded (last failure: Sep 13, 2024) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_pip_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70215&view=logs&j=8bc43b48-889f-54b9-cd8b-781ee8447bf2)** (Sep 13, 2024)
Unable to find junit file. Please see link for details.

COMMENT:
It seems reproducible since the wheel builder fails as well: https://github.com/scikit-learn/scikit-learn/issues/29830

Labels: Build / CI
⚠️ CI failed on Linux_free_threaded.pylatest_pip_free_threaded (last failure: Sep 13, 2024) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_pip_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70215&view=logs&j=8bc43b48-889f-54b9-cd8b-781ee8447bf2)** (Sep 13, 2024)
Unable to find junit file. Please see link for details.

COMMENT:
Can reproduce locally, probably an issue in Cython which has already been fixed in Cython `master` https://github.com/cython/cython/issues/6387. It should be fine tomorrow.

Labels: Build / CI
⚠️ CI failed on Linux_free_threaded.pylatest_pip_free_threaded (last failure: Sep 13, 2024) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_pip_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70215&view=logs&j=8bc43b48-889f-54b9-cd8b-781ee8447bf2)** (Sep 13, 2024)
Unable to find junit file. Please see link for details.

COMMENT:
For some reason, Cython dev wheel has not been uploaded yet for some reason, hence it still fails: https://anaconda.org/scientific-python-nightly-wheels/Cython/files

Looks like Cython nightly wheels are uploaded twice weekly (Sunday and Wednesday):
https://github.com/cython/cython/blob/7ae676645185e934c6c61b62abdb626ee905049a/.github/workflows/nightly-wheels.yml#L12C21-L12C24

See GHA logs [here](https://github.com/cython/cython/actions/workflows/nightly-wheels.yml).

Labels: Build / CI
⚠️ CI failed on Linux_free_threaded.pylatest_pip_free_threaded (last failure: Sep 13, 2024) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_pip_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70215&view=logs&j=8bc43b48-889f-54b9-cd8b-781ee8447bf2)** (Sep 13, 2024)
Unable to find junit file. Please see link for details.

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=70238&view=logs&j=8bc43b48-889f-54b9-cd8b-781ee8447bf2) on Sep 14, 2024

Labels: Build / CI