Talip7/scikit-learn-issues-multilabel huggingface dataset:
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
How about a CI that builds with nightly numpy?
Do we anticipate any breakage so far?

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
We have a nightly (not sure if it is strictly nightly or more like "every few nights") CI and so far I think it has been the normal amount of things breaking and then getting fixed.

Trying to think about it now, I realised that it might be useful for Numpy to make a list of "anticipated big changes for Numpy 2.0" where we can go and see if they've been merged already or not. As a way to get an overview of how much more there is (potentially) to come.

edit: (of course) they already have an issue like that: https://github.com/numpy/numpy/issues/24300

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
In #27899 I enabled the scikit-learn test suite to run against numpy 2.0.0.dev0. There were only two estimators to fix to get 100% of the scikit-learn test suite to pass.

So maybe we actually do not need to upper bound the dependency on numpy 2.0?

@seberg do you still envision breaking changes for numpy 2 that have not yet been implemented in the numpy dev branch?

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
I do envision a couple, although there is a reasonable chance that you won't notice, by now, I guess.  But if you do a release before we do an rc (hopefully end of the year/early next year), having the pin is probably better.

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
Thanks, we shall add the upper bound in our dependency to numpy in the scikit-learn 1.4.X release branch then.

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
With numpy 2.0.0rc1 and scipy 1.13.0 out, I think you should be able to make a numpy 2.x-compatible release now. It'd be great to see that relatively soon, since a lot of other packages are going to depend on scikit-learn for doing/testing their own numpy 2.x-compatible releases.

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
I think the next release will be 1.5.x and the plan is to get it done before May.

As an aside, the nightly from https://anaconda.org/scientific-python-nightly-wheels/scikit-learn is being built with Numpy 2. (strictly speaking the Numpy nightly). So there is some amount of testing people can do with that.

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
Just for clarity I chatted with @glemaitre to make sure my understanding was correct.

I think the plan is currently:
- do a bugfix release 1.4.3 with Numpy 2 compatibility soonish (not a new release, i.e. 1.5.x which would be a lot more work).
- start working on a 1.4.3 release candidate next week and do a release shortly after this if there are no issues

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
This is now all done, with 1.4.2 built against numpy 2.0.0rc1, right?

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
@rgommers Yes, we release 1.4.2 on PyPI and build against NumPy 2.0.0.rc1.
We did not release on (https://github.com/conda-forge/scikit-learn-feedstock/pull/251). We did not see a compatible release for SciPy 1.13. We were also not sure how the `pin_compatible` is going to work there. Do you have any advice @rgommers? Is there a migration that is going to happen on conda-forge side?

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
You can release 1.4.2 on conda-forge with the same build configuration as 1.4.1 (so built against lowest-supported numpy 1.2x.

The conda-forge team will do a coordinated rebuild for all packages to add support for 2.0 before the final 2.0.0 release. The exact details of that are still under discussion (see https://github.com/conda-forge/numpy-feedstock/issues/311 and issues linked from there); the `pin_compatible` mechanism needs some change. But that's the same for every package, so individual feedstock maintainers don't have to worry about figuring it out now.

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
Great thanks.

Labels: Packaging
Numpy 2.0 release thoughts

Some notes from the EuroSciPy maintainer track about Numpy 2.0

You can track the progress Numpy is making towards 2.0 and what changes are coming in https://github.com/numpy/numpy/issues/24300.

Some things we should consider doing:

* [ ] pin to numpy<2 in the next releases to reduce the number of people who will install a version of scikit-learn that is incompatible with the numpy 2 version
* [ ] add some code in scikit-learn that detects that numpy 2 is installed and output a good error message for users
   * Olivier: do we really need this? Maybe the upper-bound pinning is enough.
* numpy 2 might come out at the end of 2023 or early 2024
* [ ] modify existing conda-forge packages to include a numpy<2 constraint
  * unclear if we can do this on PyPi as well
  * https://github.com/conda-forge/scikit-learn-feedstock/issues/227
* [x] once numpy 2.0 has been released we should build against that instead of "oldest-supported-numpy"
  * already do this now in the nightlies?
  * make sure that this works while still having 1.x.quite-old as the minimum required numpy
  * We no longer build against `oldest-supported-numpy` for Python 3.9 thanks to #27735 that was merged in `main` before the release of scikit-learn 1.4.

cc @ogrisel

COMMENT:
So I guess we can close this one?

Labels: Packaging
bench_20newsgroups.py

### Describe the bug

```shell
usage: ipykernel_launcher.py [-h] -e
                             {dummy,random_forest,extra_trees,logistic_regression,naive_bayes,adaboost}
                             [{dummy,random_forest,extra_trees,logistic_regression,naive_bayes,adaboost} ...]
ipykernel_launcher.py: error: the following arguments are required: -e/--estimators
```

An exception has occurred, use %tb to see the full traceback.

### Steps/Code to Reproduce

```python
import argparse
from time import time

import numpy as np

from sklearn.datasets import fetch_20newsgroups_vectorized
from sklearn.dummy import DummyClassifier
from sklearn.ensemble import (
    AdaBoostClassifier,
    ExtraTreesClassifier,
    RandomForestClassifier,
)
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import accuracy_score
from sklearn.naive_bayes import MultinomialNB
from sklearn.utils.validation import check_array

ESTIMATORS = {
    "dummy": DummyClassifier(),
    "random_forest": RandomForestClassifier(max_features="sqrt", min_samples_split=10),
    "extra_trees": ExtraTreesClassifier(max_features="sqrt", min_samples_split=10),
    "logistic_regression": LogisticRegression(),
    "naive_bayes": MultinomialNB(),
    "adaboost": AdaBoostClassifier(n_estimators=10),
}

parser = argparse.ArgumentParser()
    parser.add_argument(
        "-e", "--estimators", nargs="+", required=True, choices=ESTIMATORS
    )
    args = vars(parser.parse_args())
```

### Expected Results

I dont Know

### Actual Results

```
usage: ipykernel_launcher.py [-h] -e
                             {dummy,random_forest,extra_trees,logistic_regression,naive_bayes,adaboost}
                             [{dummy,random_forest,extra_trees,logistic_regression,naive_bayes,adaboost} ...]
ipykernel_launcher.py: error: the following arguments are required: -e/--estimators
An exception has occurred, use %tb to see the full traceback.

SystemExit: 2
```


### Versions

```shell
System:
    python: 3.11.3 (main, Apr 19 2023, 23:54:32) [GCC 11.2.0]
executable: /home/narendra/anaconda3/bin/python
   machine: Linux-5.15.0-78-generic-x86_64-with-glibc2.35

Python dependencies:
      sklearn: 1.2.2
          pip: 23.1.2
   setuptools: 67.8.0
        numpy: 1.24.3
        scipy: 1.10.1
       Cython: None
       pandas: 1.5.3
   matplotlib: 3.7.1
       joblib: 1.2.0
threadpoolctl: 2.2.0

Built with OpenMP: True

threadpoolctl info:
       filepath: /home/narendra/anaconda3/lib/libmkl_rt.so.2
         prefix: libmkl_rt
       user_api: blas
   internal_api: mkl
        version: 2023.1-Product
    num_threads: 2
threading_layer: intel

       filepath: /home/narendra/anaconda3/lib/libiomp5.so
         prefix: libiomp
       user_api: openmp
   internal_api: openmp
        version: None
    num_threads: 4

       filepath: /home/narendra/anaconda3/lib/libgomp.so.1.0.0
         prefix: libgomp
       user_api: openmp
   internal_api: openmp
        version: None
    num_threads: 4
```

COMMENT:
ok, Thank you

Labels: Bug, Needs Triage