Talip7/scikit-learn-issues-multilabel huggingface dataset:
Should we continue to support compiler=intelem?

I have an build refactor removing `distutils` and `numpy.disutils` and only uses `setuptools` that successfully builds our wheels and passes tests. I think it is best to move to a pure `setuptools` implementation first, because there are still some lingering issues `meson`. For example, no editable wheels with `meson`: https://github.com/FFY00/meson-python/issues/47.

`setuptools` does not make it easy to support custom compilers: https://github.com/pypa/setuptools/issues/2806. It is doable, but it requires more complexity. (I have not got the intelem compiler fully working on our CI yet, but it is working locally in Docker).

Furthermore, I think our [Intel ICC job](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e) is not checking the Intel build correctly. Specifically, the following compiles the code correctly with `icc`:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L129

But a few lines later, we run:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L141

which overrides the icc compiled extensions with gcc compiled extensions. One can see that gcc is used in the [build logs](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e).

Also in the logs we see that `icc` itself is going to be deprecated:

```
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message.
```

Should we support continue to support and build with the Intel compiler?

CC @jeremiedbb @ogrisel

COMMENT:
Specifying ``--compiler=intelem`` is only possible using ``numpy.disutils`` (https://github.com/numpy/numpy/blob/main/numpy/distutils/intelccompiler.py). Since numpy.distutils is deprecated I guess it's natural that we stop supporting it as well.

To the question of supporting custom compilers, I'd be fine with making it simple at first and then see if we can add support later once our new build system is stable (and if we still find that there's a need for that)

Edit: I think it will still be possible to select the compiler through environment variables CC, CXX, ...

Labels: Build / CI
Should we continue to support compiler=intelem?

I have an build refactor removing `distutils` and `numpy.disutils` and only uses `setuptools` that successfully builds our wheels and passes tests. I think it is best to move to a pure `setuptools` implementation first, because there are still some lingering issues `meson`. For example, no editable wheels with `meson`: https://github.com/FFY00/meson-python/issues/47.

`setuptools` does not make it easy to support custom compilers: https://github.com/pypa/setuptools/issues/2806. It is doable, but it requires more complexity. (I have not got the intelem compiler fully working on our CI yet, but it is working locally in Docker).

Furthermore, I think our [Intel ICC job](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e) is not checking the Intel build correctly. Specifically, the following compiles the code correctly with `icc`:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L129

But a few lines later, we run:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L141

which overrides the icc compiled extensions with gcc compiled extensions. One can see that gcc is used in the [build logs](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e).

Also in the logs we see that `icc` itself is going to be deprecated:

```
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message.
```

Should we support continue to support and build with the Intel compiler?

CC @jeremiedbb @ogrisel

COMMENT:
> I have an build refactor removing distutils and numpy.disutils and only uses setuptools that successfully builds our wheels and passes tests

That's great !

Labels: Build / CI
Should we continue to support compiler=intelem?

I have an build refactor removing `distutils` and `numpy.disutils` and only uses `setuptools` that successfully builds our wheels and passes tests. I think it is best to move to a pure `setuptools` implementation first, because there are still some lingering issues `meson`. For example, no editable wheels with `meson`: https://github.com/FFY00/meson-python/issues/47.

`setuptools` does not make it easy to support custom compilers: https://github.com/pypa/setuptools/issues/2806. It is doable, but it requires more complexity. (I have not got the intelem compiler fully working on our CI yet, but it is working locally in Docker).

Furthermore, I think our [Intel ICC job](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e) is not checking the Intel build correctly. Specifically, the following compiles the code correctly with `icc`:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L129

But a few lines later, we run:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L141

which overrides the icc compiled extensions with gcc compiled extensions. One can see that gcc is used in the [build logs](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e).

Also in the logs we see that `icc` itself is going to be deprecated:

```
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message.
```

Should we support continue to support and build with the Intel compiler?

CC @jeremiedbb @ogrisel

COMMENT:
Been worried about the whole distutils issue. I think this makes sense. Thanks for the work @thomasjpfan

Labels: Build / CI
Should we continue to support compiler=intelem?

I have an build refactor removing `distutils` and `numpy.disutils` and only uses `setuptools` that successfully builds our wheels and passes tests. I think it is best to move to a pure `setuptools` implementation first, because there are still some lingering issues `meson`. For example, no editable wheels with `meson`: https://github.com/FFY00/meson-python/issues/47.

`setuptools` does not make it easy to support custom compilers: https://github.com/pypa/setuptools/issues/2806. It is doable, but it requires more complexity. (I have not got the intelem compiler fully working on our CI yet, but it is working locally in Docker).

Furthermore, I think our [Intel ICC job](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e) is not checking the Intel build correctly. Specifically, the following compiles the code correctly with `icc`:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L129

But a few lines later, we run:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L141

which overrides the icc compiled extensions with gcc compiled extensions. One can see that gcc is used in the [build logs](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e).

Also in the logs we see that `icc` itself is going to be deprecated:

```
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message.
```

Should we support continue to support and build with the Intel compiler?

CC @jeremiedbb @ogrisel

COMMENT:
Adding to the meson-related discussion here, I was recently playing with the editable installs (https://github.com/mesonbuild/meson-python/issues/47) with meson and meson-python and it is nice.

Some thoughts: I've also found using meson to be quite useful and fast in developing a scikit-learn compatible package (https://github.com/neurodata/scikit-tree). Some cons are that using meson needs some getting used to, and there are some weird things you can't easily do (like run Python in the same root directory). But one can use spin (https://github.com/scientific-python/spin) to make the developer exp easier. I will say the `meson.build` files are also way easier to read and parse and understand compared to mega setup.py files.

Labels: Build / CI
Should we continue to support compiler=intelem?

I have an build refactor removing `distutils` and `numpy.disutils` and only uses `setuptools` that successfully builds our wheels and passes tests. I think it is best to move to a pure `setuptools` implementation first, because there are still some lingering issues `meson`. For example, no editable wheels with `meson`: https://github.com/FFY00/meson-python/issues/47.

`setuptools` does not make it easy to support custom compilers: https://github.com/pypa/setuptools/issues/2806. It is doable, but it requires more complexity. (I have not got the intelem compiler fully working on our CI yet, but it is working locally in Docker).

Furthermore, I think our [Intel ICC job](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e) is not checking the Intel build correctly. Specifically, the following compiles the code correctly with `icc`:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L129

But a few lines later, we run:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L141

which overrides the icc compiled extensions with gcc compiled extensions. One can see that gcc is used in the [build logs](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e).

Also in the logs we see that `icc` itself is going to be deprecated:

```
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message.
```

Should we support continue to support and build with the Intel compiler?

CC @jeremiedbb @ogrisel

COMMENT:
With the recent inclusion of executable examples in the browser using JupyterLite in https://github.com/scikit-learn/scikit-learn/pull/25887, I prefer for meson to work with Pyodide before switching over. Currently there is work to get SciPy to build with Pyodide here: https://github.com/pyodide/pyodide/pull/3649

Labels: Build / CI
Should we continue to support compiler=intelem?

I have an build refactor removing `distutils` and `numpy.disutils` and only uses `setuptools` that successfully builds our wheels and passes tests. I think it is best to move to a pure `setuptools` implementation first, because there are still some lingering issues `meson`. For example, no editable wheels with `meson`: https://github.com/FFY00/meson-python/issues/47.

`setuptools` does not make it easy to support custom compilers: https://github.com/pypa/setuptools/issues/2806. It is doable, but it requires more complexity. (I have not got the intelem compiler fully working on our CI yet, but it is working locally in Docker).

Furthermore, I think our [Intel ICC job](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e) is not checking the Intel build correctly. Specifically, the following compiles the code correctly with `icc`:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L129

But a few lines later, we run:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L141

which overrides the icc compiled extensions with gcc compiled extensions. One can see that gcc is used in the [build logs](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e).

Also in the logs we see that `icc` itself is going to be deprecated:

```
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message.
```

Should we support continue to support and build with the Intel compiler?

CC @jeremiedbb @ogrisel

COMMENT:
Yes, @lesteve was looking into building scikit-image with meson for Pyodide in https://github.com/pyodide/pyodide/pull/3874 which would be more comparable to scikit-learn build-wise. Scipy is another story.

Labels: Build / CI
Should we continue to support compiler=intelem?

I have an build refactor removing `distutils` and `numpy.disutils` and only uses `setuptools` that successfully builds our wheels and passes tests. I think it is best to move to a pure `setuptools` implementation first, because there are still some lingering issues `meson`. For example, no editable wheels with `meson`: https://github.com/FFY00/meson-python/issues/47.

`setuptools` does not make it easy to support custom compilers: https://github.com/pypa/setuptools/issues/2806. It is doable, but it requires more complexity. (I have not got the intelem compiler fully working on our CI yet, but it is working locally in Docker).

Furthermore, I think our [Intel ICC job](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e) is not checking the Intel build correctly. Specifically, the following compiles the code correctly with `icc`:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L129

But a few lines later, we run:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L141

which overrides the icc compiled extensions with gcc compiled extensions. One can see that gcc is used in the [build logs](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e).

Also in the logs we see that `icc` itself is going to be deprecated:

```
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message.
```

Should we support continue to support and build with the Intel compiler?

CC @jeremiedbb @ogrisel

COMMENT:
I am going to close this one. There does not seem there has any demand for this, if this changes we can have a closer look.

I guess if someone has any interest with support Intel compilers with the Meson build, my advise would be to create a separate issue. Setting `CC` et al would be the first option. There may also be improvements to our `meson.build` files. There is a scipy issue about supporting Intel compilers that may be have some useful info, see https://github.com/scipy/scipy/issues/17075.

Labels: Build / CI
Should we continue to support compiler=intelem?

I have an build refactor removing `distutils` and `numpy.disutils` and only uses `setuptools` that successfully builds our wheels and passes tests. I think it is best to move to a pure `setuptools` implementation first, because there are still some lingering issues `meson`. For example, no editable wheels with `meson`: https://github.com/FFY00/meson-python/issues/47.

`setuptools` does not make it easy to support custom compilers: https://github.com/pypa/setuptools/issues/2806. It is doable, but it requires more complexity. (I have not got the intelem compiler fully working on our CI yet, but it is working locally in Docker).

Furthermore, I think our [Intel ICC job](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e) is not checking the Intel build correctly. Specifically, the following compiles the code correctly with `icc`:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L129

But a few lines later, we run:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L141

which overrides the icc compiled extensions with gcc compiled extensions. One can see that gcc is used in the [build logs](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e).

Also in the logs we see that `icc` itself is going to be deprecated:

```
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message.
```

Should we support continue to support and build with the Intel compiler?

CC @jeremiedbb @ogrisel

COMMENT:
Note that Spack has CI pipelines that exercise this. It should work, and otherwise there'll be a report at some point.

Labels: Build / CI
Should we continue to support compiler=intelem?

I have an build refactor removing `distutils` and `numpy.disutils` and only uses `setuptools` that successfully builds our wheels and passes tests. I think it is best to move to a pure `setuptools` implementation first, because there are still some lingering issues `meson`. For example, no editable wheels with `meson`: https://github.com/FFY00/meson-python/issues/47.

`setuptools` does not make it easy to support custom compilers: https://github.com/pypa/setuptools/issues/2806. It is doable, but it requires more complexity. (I have not got the intelem compiler fully working on our CI yet, but it is working locally in Docker).

Furthermore, I think our [Intel ICC job](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e) is not checking the Intel build correctly. Specifically, the following compiles the code correctly with `icc`:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L129

But a few lines later, we run:

https://github.com/scikit-learn/scikit-learn/blob/681ab94222a9ba5f7b39f768f0ab92873905541a/build_tools/azure/install.sh#L141

which overrides the icc compiled extensions with gcc compiled extensions. One can see that gcc is used in the [build logs](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=47113&view=logs&j=8628a494-79d0-53fa-274c-1b00464f7121&t=044d955c-661f-5416-d272-56c1ab35449e).

Also in the logs we see that `icc` itself is going to be deprecated:

```
icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler. Use '-diag-disable=10441' to disable this message.
```

Should we support continue to support and build with the Intel compiler?

CC @jeremiedbb @ogrisel

COMMENT:
> Note that Spack has CI pipelines that exercise this. It should work, and otherwise there'll be a report at some point.

OK great to hear, it seems indeed there is some kind of scikit-learn Spack recipe: https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/py-scikit-learn/package.py

Labels: Build / CI
Add TQDM progress bar to .fit

### Describe the workflow you want to enable

There is no cohesive way of knowing when a classifier will finish training. What is shown by `verbose = True` is not consistent across models. 

### Describe your proposed solution

I propose wrapping all most/all `.fit()` functions in tqdm.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
Hi @FinAminToastCrunch, this has been asked several times, for example in https://github.com/scikit-learn/scikit-learn/issues/7574, and is part of the more general question of having callbacks in sklearn. There's ongoing work on this subject in https://github.com/scikit-learn/scikit-learn/pull/22000.

I'm closing this issue as duplicate.

Labels: New Feature, Needs Triage
Add TQDM progress bar to .fit

### Describe the workflow you want to enable

There is no cohesive way of knowing when a classifier will finish training. What is shown by `verbose = True` is not consistent across models. 

### Describe your proposed solution

I propose wrapping all most/all `.fit()` functions in tqdm.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
Add TQDM progress bar to .fit still working in progress?
after two years ;)

Labels: New Feature, Needs Triage
Deprecate the kwargs argument of utils.extmath.density

The function ``density`` from sklearn.utils.extmath accepts extra kwargs but completely ignore them. I suggest we deprecate this.

Here's a guide on how to proceed: https://scikit-learn.org/stable/developers/contributing.html#maintaining-backwards-compatibility

A future warning should only be raised if an extra kwarg is actually passed to the function.

COMMENT:
/take

Labels: Easy, API