Talip7/scikit-learn-issues-multilabel huggingface dataset:
Polars not mentioned as requirement to build documentation

### Describe the issue linked to the documentation

The developer documentation [here](https://scikit-learn.org/dev/developers/contributing.html#building-the-documentation) lists the dependencies required to build the documentation. However, `polars` is not mentioned as a required dependency leading to the following error:
```bash
    Traceback (most recent call last):
      File "/.../scikit-learn/examples/release_highlights/plot_release_highlights_1_4_0.py", line 58, in <module>
        import polars as pl
    ModuleNotFoundError: No module named 'polars'
```

It seems that since version 1.4.0, polars is now also supported.

### Suggest a potential alternative/fix

The easiest fix would be to add `polars` in the documentation [here](https://scikit-learn.org/dev/developers/contributing.html#building-the-documentation) as a needed dependency.
Alternatively, a `requirements.txt` could be created with all the needed dependencies for development - although sure I'm this must have already been discussed in the past and there should be reasons against it.

COMMENT:
My understanding is that right now `_min_dependencies.py` is the source of truth and we have tests that checks that `pyproject.toml` is consistent with `min_dependencies.py` see https://github.com/scikit-learn/scikit-learn/blob/9b7d176b5a85d7dd681ffa69e55a82a3338096c5/sklearn/tests/test_min_dependencies_readme.py#L56. I would think sticking with this approach is fine.

I think you can already do `pip install -e .[doc] --no-use-pep517 --no-build-isolation` (although I guess nobody does that) at least there is a `doc` `extra_requires` in `setup.py` built from `_min_dependencies.py`. This is why by the way I added them in `pyproject.toml` in the "Meson as main build tool PR" https://github.com/scikit-learn/scikit-learn/pull/28506

Labels: Documentation
Polars not mentioned as requirement to build documentation

### Describe the issue linked to the documentation

The developer documentation [here](https://scikit-learn.org/dev/developers/contributing.html#building-the-documentation) lists the dependencies required to build the documentation. However, `polars` is not mentioned as a required dependency leading to the following error:
```bash
    Traceback (most recent call last):
      File "/.../scikit-learn/examples/release_highlights/plot_release_highlights_1_4_0.py", line 58, in <module>
        import polars as pl
    ModuleNotFoundError: No module named 'polars'
```

It seems that since version 1.4.0, polars is now also supported.

### Suggest a potential alternative/fix

The easiest fix would be to add `polars` in the documentation [here](https://scikit-learn.org/dev/developers/contributing.html#building-the-documentation) as a needed dependency.
Alternatively, a `requirements.txt` could be created with all the needed dependencies for development - although sure I'm this must have already been discussed in the past and there should be reasons against it.

COMMENT:
> This is why by the way I added them in pyproject.toml in the "Meson as main build tool PR" https://github.com/scikit-learn/scikit-learn/pull/28506

Indeed, I forgot about that.

Let's focus on reviewing and merging #28506 first and then update the documentation on how to build the doc in a second stage then.

Labels: Documentation
Dubious claim in accuracy_score doc about being equal to jaccard_score

### Describe the issue linked to the documentation

The documentation for [`accuracy_score`](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.accuracy_score.html#sklearn.metrics.accuracy_score) claims the following:

> In binary classification, this function is equal to the `jaccard_score` function.

However, that just doesn't seem to be true, both in theory and in practice.

In theory:

* Jaccard index = TP / (TP + FP + FN)
* Accuracy = (TP + TN) / (TP + TN + FP + FN)

Accuracy includes true negatives, while the Jaccard index doesn't.

In practice:

```
>>> sklearn.metrics.jaccard_score([0, 1, 0, 1], [0, 0, 1, 1])
0.3333333333333333
>>> sklearn.metrics.accuracy_score([0, 1, 0, 1], [0, 0, 1, 1])
0.5
```


### Suggest a potential alternative/fix

I think this claim can just be removed.

COMMENT:
I agree with your analysis and suggested fix. Feel free to open a PR, otherwise I can take care of it.

Labels: Bug, Documentation
Dubious claim in accuracy_score doc about being equal to jaccard_score

### Describe the issue linked to the documentation

The documentation for [`accuracy_score`](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.accuracy_score.html#sklearn.metrics.accuracy_score) claims the following:

> In binary classification, this function is equal to the `jaccard_score` function.

However, that just doesn't seem to be true, both in theory and in practice.

In theory:

* Jaccard index = TP / (TP + FP + FN)
* Accuracy = (TP + TN) / (TP + TN + FP + FN)

Accuracy includes true negatives, while the Jaccard index doesn't.

In practice:

```
>>> sklearn.metrics.jaccard_score([0, 1, 0, 1], [0, 0, 1, 1])
0.3333333333333333
>>> sklearn.metrics.accuracy_score([0, 1, 0, 1], [0, 0, 1, 1])
0.5
```


### Suggest a potential alternative/fix

I think this claim can just be removed.

COMMENT:
/take

Labels: Bug, Documentation
Support pyenv to manage development python version

### Describe the workflow you want to enable

The [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) for installing the development version of scikit-learn proposes two ways for the developer to manage their python version: 1) conda; 2) or the system's python version (for linux users).
My proposal would be to allow developers to also use the popular tool [pyenv](https://github.com/pyenv/pyenv) to manage their python version. Although there is nothing preventing the developer from using pyenv now, they have to be mindful of not committing the `.python-version` file when making a PR.

### Describe your proposed solution

The following additions could be positive quality of life improvements for developers wanting to use `pyenv` for managing their python version when contributing:
- Adding the `.python-version` file to the `.gitignore`.
- (Optionally) Mention in the [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) that other tools can be used to manage the python version. E.g., the following text could be used on point 3 of [this](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) installation guide:
>**3. Alternative to conda:** You can use your system's Python provided it is recent enough (3.8 or higher at the time of writing), or use a third-party tool like `pyenv` to manage you python version. (...)`

### Describe alternatives you've considered, if relevant
N/A

### Additional context
N/A

_Note:_ I'll be happy to contribute a PR for this is you believe that it could be useful.

COMMENT:
I'm fine with both points in the proposal.

Labels: Documentation
Support pyenv to manage development python version

### Describe the workflow you want to enable

The [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) for installing the development version of scikit-learn proposes two ways for the developer to manage their python version: 1) conda; 2) or the system's python version (for linux users).
My proposal would be to allow developers to also use the popular tool [pyenv](https://github.com/pyenv/pyenv) to manage their python version. Although there is nothing preventing the developer from using pyenv now, they have to be mindful of not committing the `.python-version` file when making a PR.

### Describe your proposed solution

The following additions could be positive quality of life improvements for developers wanting to use `pyenv` for managing their python version when contributing:
- Adding the `.python-version` file to the `.gitignore`.
- (Optionally) Mention in the [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) that other tools can be used to manage the python version. E.g., the following text could be used on point 3 of [this](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) installation guide:
>**3. Alternative to conda:** You can use your system's Python provided it is recent enough (3.8 or higher at the time of writing), or use a third-party tool like `pyenv` to manage you python version. (...)`

### Describe alternatives you've considered, if relevant
N/A

### Additional context
N/A

_Note:_ I'll be happy to contribute a PR for this is you believe that it could be useful.

COMMENT:
> I'm fine with both points in the proposal.

Great. Will start working on the PR for this then

Labels: Documentation
Support pyenv to manage development python version

### Describe the workflow you want to enable

The [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) for installing the development version of scikit-learn proposes two ways for the developer to manage their python version: 1) conda; 2) or the system's python version (for linux users).
My proposal would be to allow developers to also use the popular tool [pyenv](https://github.com/pyenv/pyenv) to manage their python version. Although there is nothing preventing the developer from using pyenv now, they have to be mindful of not committing the `.python-version` file when making a PR.

### Describe your proposed solution

The following additions could be positive quality of life improvements for developers wanting to use `pyenv` for managing their python version when contributing:
- Adding the `.python-version` file to the `.gitignore`.
- (Optionally) Mention in the [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) that other tools can be used to manage the python version. E.g., the following text could be used on point 3 of [this](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) installation guide:
>**3. Alternative to conda:** You can use your system's Python provided it is recent enough (3.8 or higher at the time of writing), or use a third-party tool like `pyenv` to manage you python version. (...)`

### Describe alternatives you've considered, if relevant
N/A

### Additional context
N/A

_Note:_ I'll be happy to contribute a PR for this is you believe that it could be useful.

COMMENT:
Personally I am fine adding `.python-version` to the `.gitignore` but I am not fully convinced we want to mention that pyenv can be used. Adding more options can be confusing because people don't know which one to use.

Labels: Documentation
Support pyenv to manage development python version

### Describe the workflow you want to enable

The [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) for installing the development version of scikit-learn proposes two ways for the developer to manage their python version: 1) conda; 2) or the system's python version (for linux users).
My proposal would be to allow developers to also use the popular tool [pyenv](https://github.com/pyenv/pyenv) to manage their python version. Although there is nothing preventing the developer from using pyenv now, they have to be mindful of not committing the `.python-version` file when making a PR.

### Describe your proposed solution

The following additions could be positive quality of life improvements for developers wanting to use `pyenv` for managing their python version when contributing:
- Adding the `.python-version` file to the `.gitignore`.
- (Optionally) Mention in the [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) that other tools can be used to manage the python version. E.g., the following text could be used on point 3 of [this](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) installation guide:
>**3. Alternative to conda:** You can use your system's Python provided it is recent enough (3.8 or higher at the time of writing), or use a third-party tool like `pyenv` to manage you python version. (...)`

### Describe alternatives you've considered, if relevant
N/A

### Additional context
N/A

_Note:_ I'll be happy to contribute a PR for this is you believe that it could be useful.

COMMENT:
> Adding more options can be confusing because people don't know which one to use.

The "how to setup stuff" section is already hard to follow so I think I am -0 on adding more options. I wonder if pyenv users are like mamba users: you don't need to tell mamba users to use mamba, if they see `conda` they are going to replace it with `mamba`.

Labels: Documentation
Support pyenv to manage development python version

### Describe the workflow you want to enable

The [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) for installing the development version of scikit-learn proposes two ways for the developer to manage their python version: 1) conda; 2) or the system's python version (for linux users).
My proposal would be to allow developers to also use the popular tool [pyenv](https://github.com/pyenv/pyenv) to manage their python version. Although there is nothing preventing the developer from using pyenv now, they have to be mindful of not committing the `.python-version` file when making a PR.

### Describe your proposed solution

The following additions could be positive quality of life improvements for developers wanting to use `pyenv` for managing their python version when contributing:
- Adding the `.python-version` file to the `.gitignore`.
- (Optionally) Mention in the [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) that other tools can be used to manage the python version. E.g., the following text could be used on point 3 of [this](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) installation guide:
>**3. Alternative to conda:** You can use your system's Python provided it is recent enough (3.8 or higher at the time of writing), or use a third-party tool like `pyenv` to manage you python version. (...)`

### Describe alternatives you've considered, if relevant
N/A

### Additional context
N/A

_Note:_ I'll be happy to contribute a PR for this is you believe that it could be useful.

COMMENT:
That's a valid concern indeed.

Labels: Documentation
Support pyenv to manage development python version

### Describe the workflow you want to enable

The [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) for installing the development version of scikit-learn proposes two ways for the developer to manage their python version: 1) conda; 2) or the system's python version (for linux users).
My proposal would be to allow developers to also use the popular tool [pyenv](https://github.com/pyenv/pyenv) to manage their python version. Although there is nothing preventing the developer from using pyenv now, they have to be mindful of not committing the `.python-version` file when making a PR.

### Describe your proposed solution

The following additions could be positive quality of life improvements for developers wanting to use `pyenv` for managing their python version when contributing:
- Adding the `.python-version` file to the `.gitignore`.
- (Optionally) Mention in the [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) that other tools can be used to manage the python version. E.g., the following text could be used on point 3 of [this](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) installation guide:
>**3. Alternative to conda:** You can use your system's Python provided it is recent enough (3.8 or higher at the time of writing), or use a third-party tool like `pyenv` to manage you python version. (...)`

### Describe alternatives you've considered, if relevant
N/A

### Additional context
N/A

_Note:_ I'll be happy to contribute a PR for this is you believe that it could be useful.

COMMENT:
OK so let's go modifying only the `.gitignore` that could be annoying when developing.

Labels: Documentation
Support pyenv to manage development python version

### Describe the workflow you want to enable

The [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) for installing the development version of scikit-learn proposes two ways for the developer to manage their python version: 1) conda; 2) or the system's python version (for linux users).
My proposal would be to allow developers to also use the popular tool [pyenv](https://github.com/pyenv/pyenv) to manage their python version. Although there is nothing preventing the developer from using pyenv now, they have to be mindful of not committing the `.python-version` file when making a PR.

### Describe your proposed solution

The following additions could be positive quality of life improvements for developers wanting to use `pyenv` for managing their python version when contributing:
- Adding the `.python-version` file to the `.gitignore`.
- (Optionally) Mention in the [documentation](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) that other tools can be used to manage the python version. E.g., the following text could be used on point 3 of [this](https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn) installation guide:
>**3. Alternative to conda:** You can use your system's Python provided it is recent enough (3.8 or higher at the time of writing), or use a third-party tool like `pyenv` to manage you python version. (...)`

### Describe alternatives you've considered, if relevant
N/A

### Additional context
N/A

_Note:_ I'll be happy to contribute a PR for this is you believe that it could be useful.

COMMENT:
Let's move the discussion into the #28655 PR as the paragraph can at least benefit from an update with the minimum Python version (3.8 vs 3.9).

Labels: Documentation
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/8320966198)** (Mar 18, 2024)

```
  ________________________ ERROR collecting test session _________________________
  /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/__init__.py:126: in import_module
      return _bootstrap._gcd_import(name[level:], package, level)
  <frozen importlib._bootstrap>:1050: in _gcd_import
      ???
  <frozen importlib._bootstrap>:1027: in _find_and_load
      ???
  <frozen importlib._bootstrap>:1006: in _find_and_load_unlocked
      ???
  <frozen importlib._bootstrap>:688: in _load_unlocked
      ???
  ../venv-test-arm64/lib/python3.10/site-packages/_pytest/assertion/rewrite.py:178: in exec_module
      exec(co, module.__dict__)
  ../venv-test-arm64/lib/python3.10/site-packages/sklearn/conftest.py:17: in <module>
      from sklearn.datasets import (
  ../venv-test-arm64/lib/python3.10/site-packages/sklearn/datasets/__init__.py:8: in <module>
      from ._base import (
  ../venv-test-arm64/lib/python3.10/site-packages/sklearn/datasets/_base.py:27: in <module>
      from ..preprocessing import scale
  ../venv-test-arm64/lib/python3.10/site-packages/sklearn/preprocessing/__init__.py:31: in <module>
      from ._target_encoder import TargetEncoder
  ../venv-test-arm64/lib/python3.10/site-packages/sklearn/preprocessing/_target_encoder.py:15: in <module>
      from ._target_encoder_fast import _fit_encoding_fast, _fit_encoding_fast_auto_smooth
  sklearn/preprocessing/_target_encoder_fast.pyx:1: in init sklearn.preprocessing._target_encoder_fast
      ???
  E   ValueError: numpy.broadcast size changed, may indicate binary incompatibility. Expected 816 from C header, got 560 from PyObject
  =========================== short test summary info ============================
  ERROR  - ValueError: numpy.broadcast size changed, may indicate binary incompatibility. Expected 816 from C header, got 560 from PyObject
```

COMMENT:
Not a good news because it seems that building with NumPy 2 and having NumPy < 2 at runtime does not work.

Labels: Bug, Build / CI
⚠️ CI failed on Wheel builder ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/8320966198)** (Mar 18, 2024)

```
  ________________________ ERROR collecting test session _________________________
  /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/__init__.py:126: in import_module
      return _bootstrap._gcd_import(name[level:], package, level)
  <frozen importlib._bootstrap>:1050: in _gcd_import
      ???
  <frozen importlib._bootstrap>:1027: in _find_and_load
      ???
  <frozen importlib._bootstrap>:1006: in _find_and_load_unlocked
      ???
  <frozen importlib._bootstrap>:688: in _load_unlocked
      ???
  ../venv-test-arm64/lib/python3.10/site-packages/_pytest/assertion/rewrite.py:178: in exec_module
      exec(co, module.__dict__)
  ../venv-test-arm64/lib/python3.10/site-packages/sklearn/conftest.py:17: in <module>
      from sklearn.datasets import (
  ../venv-test-arm64/lib/python3.10/site-packages/sklearn/datasets/__init__.py:8: in <module>
      from ._base import (
  ../venv-test-arm64/lib/python3.10/site-packages/sklearn/datasets/_base.py:27: in <module>
      from ..preprocessing import scale
  ../venv-test-arm64/lib/python3.10/site-packages/sklearn/preprocessing/__init__.py:31: in <module>
      from ._target_encoder import TargetEncoder
  ../venv-test-arm64/lib/python3.10/site-packages/sklearn/preprocessing/_target_encoder.py:15: in <module>
      from ._target_encoder_fast import _fit_encoding_fast, _fit_encoding_fast_auto_smooth
  sklearn/preprocessing/_target_encoder_fast.pyx:1: in init sklearn.preprocessing._target_encoder_fast
      ???
  E   ValueError: numpy.broadcast size changed, may indicate binary incompatibility. Expected 816 from C header, got 560 from PyObject
  =========================== short test summary info ============================
  ERROR  - ValueError: numpy.broadcast size changed, may indicate binary incompatibility. Expected 816 from C header, got 560 from PyObject
```

COMMENT:
I can reproduce locally, this seems like a recent numpy regression since this build started to fail yesterday (Sunday March 17), cc @seberg to see whether a recent change in numpy could have caused this.

The error is (to have it in the same post):
```
ValueError: numpy.broadcast size changed, may indicate binary incompatibility. Expected 816 from C header, got 560 from PyObject
```

I found another case where a similar issue occured https://github.com/numpy/numpy/issues/25275 although this may be the same symptom but a completely different root cause.

Labels: Bug, Build / CI