Talip7/scikit-learn-issues-multilabel huggingface dataset:
Cannot recover DBSCAN from memory-overuse

### Describe the bug

I also just ran into this issue that the program gets killed when running DBSCAN, similar to:
https://github.com/scikit-learn/scikit-learn/issues/22531

The documentation update already helps and I think it's ok for the algorithm to fail. But currently there is no way for me to recover, and a more informative error message would be useful. Since now DBSCAN just reports `killed` and it requires a bit of search to see what fails:
```
>>> DBSCAN(eps=1, min_samples=2).fit(np.random.rand(10_000_000, 3))
Killed
```

e.g., something like how `numpy` does it:
```
>>> n = int(1e6)
>>> np.random.rand(n, n)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "numpy/random/mtrand.pyx", line 1219, in numpy.random.mtrand.RandomState.rand
  File "numpy/random/mtrand.pyx", line 437, in numpy.random.mtrand.RandomState.random_sample
  File "_common.pyx", line 307, in numpy.random._common.double_fill
numpy.core._exceptions._ArrayMemoryError: Unable to allocate 7.28 TiB for an array with shape (1000000, 1000000) and data type float64
```

Additionally, I noted that the memory accumulated with consecutive calling of DBSCAN. Which can lead to a killed program even though there is enough memory when running a single fit.
I was able to resolve this by explicitly calling `import gc; gc.collect()` after each run. Maybe this could be invoked at the end of each DBSCAN fit?

### Steps/Code to Reproduce

```python
try:
    DBSCAN(eps=1, min_samples=2).fit(np.random.rand(10_000_000, 3))
except:
    print("Caught exception")
```


### Expected Results

```python
Caught exception
```

### Actual Results

```python
Killed
```

### Versions

```shell
>>> import sklearn; sklearn.show_versions()

System:
    python: 3.10.12 (main, Feb  4 2025, 14:57:36) [GCC 11.4.0]
executable: /usr/bin/python3
   machine: Linux-6.14.6-arch1-1-x86_64-with-glibc2.35

Python dependencies:
      sklearn: 1.6.1
          pip: None
   setuptools: 80.7.1
        numpy: 1.26.4
        scipy: 1.15.3
       Cython: None
       pandas: 2.2.3
   matplotlib: 3.10.3
       joblib: 1.5.0
threadpoolctl: 3.6.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 20
         prefix: libopenblas
       filepath: /usr/local/lib/python3.10/dist-packages/numpy.libs/libopenblas64_p-r0-0cf96a72.3.23.dev.so
        version: 0.3.23.dev
threading_layer: pthreads
   architecture: Prescott

       user_api: blas
   internal_api: openblas
    num_threads: 20
         prefix: libscipy_openblas
       filepath: /usr/local/lib/python3.10/dist-packages/scipy.libs/libscipy_openblas-68440149.so
        version: 0.3.28
threading_layer: pthreads
   architecture: Haswell

       user_api: openmp
   internal_api: openmp
    num_threads: 20
         prefix: libgomp
       filepath: /usr/local/lib/python3.10/dist-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
```

COMMENT:
Hi, can I work on this issue? I’m new to sklearn contributions and would like to take this up.

Labels: Bug, help wanted, Hard, Needs Reproducible Code, Needs Investigation
Cannot recover DBSCAN from memory-overuse

### Describe the bug

I also just ran into this issue that the program gets killed when running DBSCAN, similar to:
https://github.com/scikit-learn/scikit-learn/issues/22531

The documentation update already helps and I think it's ok for the algorithm to fail. But currently there is no way for me to recover, and a more informative error message would be useful. Since now DBSCAN just reports `killed` and it requires a bit of search to see what fails:
```
>>> DBSCAN(eps=1, min_samples=2).fit(np.random.rand(10_000_000, 3))
Killed
```

e.g., something like how `numpy` does it:
```
>>> n = int(1e6)
>>> np.random.rand(n, n)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "numpy/random/mtrand.pyx", line 1219, in numpy.random.mtrand.RandomState.rand
  File "numpy/random/mtrand.pyx", line 437, in numpy.random.mtrand.RandomState.random_sample
  File "_common.pyx", line 307, in numpy.random._common.double_fill
numpy.core._exceptions._ArrayMemoryError: Unable to allocate 7.28 TiB for an array with shape (1000000, 1000000) and data type float64
```

Additionally, I noted that the memory accumulated with consecutive calling of DBSCAN. Which can lead to a killed program even though there is enough memory when running a single fit.
I was able to resolve this by explicitly calling `import gc; gc.collect()` after each run. Maybe this could be invoked at the end of each DBSCAN fit?

### Steps/Code to Reproduce

```python
try:
    DBSCAN(eps=1, min_samples=2).fit(np.random.rand(10_000_000, 3))
except:
    print("Caught exception")
```


### Expected Results

```python
Caught exception
```

### Actual Results

```python
Killed
```

### Versions

```shell
>>> import sklearn; sklearn.show_versions()

System:
    python: 3.10.12 (main, Feb  4 2025, 14:57:36) [GCC 11.4.0]
executable: /usr/bin/python3
   machine: Linux-6.14.6-arch1-1-x86_64-with-glibc2.35

Python dependencies:
      sklearn: 1.6.1
          pip: None
   setuptools: 80.7.1
        numpy: 1.26.4
        scipy: 1.15.3
       Cython: None
       pandas: 2.2.3
   matplotlib: 3.10.3
       joblib: 1.5.0
threadpoolctl: 3.6.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 20
         prefix: libopenblas
       filepath: /usr/local/lib/python3.10/dist-packages/numpy.libs/libopenblas64_p-r0-0cf96a72.3.23.dev.so
        version: 0.3.23.dev
threading_layer: pthreads
   architecture: Prescott

       user_api: blas
   internal_api: openblas
    num_threads: 20
         prefix: libscipy_openblas
       filepath: /usr/local/lib/python3.10/dist-packages/scipy.libs/libscipy_openblas-68440149.so
        version: 0.3.28
threading_layer: pthreads
   architecture: Haswell

       user_api: openmp
   internal_api: openmp
    num_threads: 20
         prefix: libgomp
       filepath: /usr/local/lib/python3.10/dist-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
```

COMMENT:
Just FYI, we'll close the issue if no reproducer is provided in a couple of weeks.

Labels: Bug, help wanted, Hard, Needs Reproducible Code, Needs Investigation
[PCA] ValueError: too many values to unpack (expected 3)

### Describe the bug

I am getting the following error when running PCA with version 1.6.1:

<img width="956" alt="Image" src="https://github.com/user-attachments/assets/4a576ca3-2268-45c0-8fa8-cccea16fce6d" />



### Steps/Code to Reproduce

You can reproduce it with this snippet: 

```
import numpy as np
from sklearn.decomposition import PCA

X = np.random.choice([0, 1], size=(10, 2048), p=[0.7, 0.3])
print(X.shape, X.dtype)

pca = PCA(n_components=2)
pca.fit_transform(X)
print(pca.explained_variance_ratio_)
print(pca.singular_values_)

```



### Expected Results

This works with version `1.3.2`. 

```
(10, 2048) int64
[0.12276184 0.11835199]
[21.7604452  21.36603173]
```



I tried using `svd_solver='arpack'`, but that does not help in my desperate attempts to solve the issue.  Why did this stop working after `1.3.2`?  For now, I just rolled back to `1.3.2`. 


Thanks

### Actual Results

<img width="956" alt="Image" src="https://github.com/user-attachments/assets/eaea3acd-7429-4497-9b14-b2c121fe1918" />

### Versions

```shell
Version with the error `1.6.1`. Version that works for me: `1.3.2`.
```

COMMENT:
This is interesting, I tried the snippet on my MacBook Pro and it works: 


```
import numpy as np
from sklearn.decomposition import PCA
import sklearn

print(sklearn.__version__)

X = np.random.choice([0, 1], size=(10, 2048), p=[0.7, 0.3])
print(X.shape, X.dtype)

pca = PCA(n_components=2)
pca.fit_transform(X)
print(pca.explained_variance_ratio_)
print(pca.singular_values_)
```

```
1.6.1
(10, 2048) int64
[0.1256885  0.12096747]
[22.03199875 21.61426301]
```

The problem I presented above is happening on a Docker image I created locally. I'll keep investigating what should be causing the issue.

Labels: Bug, Needs Triage
[PCA] ValueError: too many values to unpack (expected 3)

### Describe the bug

I am getting the following error when running PCA with version 1.6.1:

<img width="956" alt="Image" src="https://github.com/user-attachments/assets/4a576ca3-2268-45c0-8fa8-cccea16fce6d" />



### Steps/Code to Reproduce

You can reproduce it with this snippet: 

```
import numpy as np
from sklearn.decomposition import PCA

X = np.random.choice([0, 1], size=(10, 2048), p=[0.7, 0.3])
print(X.shape, X.dtype)

pca = PCA(n_components=2)
pca.fit_transform(X)
print(pca.explained_variance_ratio_)
print(pca.singular_values_)

```



### Expected Results

This works with version `1.3.2`. 

```
(10, 2048) int64
[0.12276184 0.11835199]
[21.7604452  21.36603173]
```



I tried using `svd_solver='arpack'`, but that does not help in my desperate attempts to solve the issue.  Why did this stop working after `1.3.2`?  For now, I just rolled back to `1.3.2`. 


Thanks

### Actual Results

<img width="956" alt="Image" src="https://github.com/user-attachments/assets/eaea3acd-7429-4497-9b14-b2c121fe1918" />

### Versions

```shell
Version with the error `1.6.1`. Version that works for me: `1.3.2`.
```

COMMENT:
I can't reproduce the issue with your snippet. Quickly looking at your first stack-trace screenshot, it looks like you are using scikit-learn-intelex (`sklearnex` in the name of the folder). scikit-learn-intelex is a separate package try to open an issue in their bug tracker.

I am going to close this issue, but feel free to reopen if there is a clear indication that there is an issue in scikit-learn.

Also, please copy and paste text rather than use screenshots next time 🙏. For example, it makes the error more easily searchable.

Labels: Bug, Needs Triage
[PCA] ValueError: too many values to unpack (expected 3)

### Describe the bug

I am getting the following error when running PCA with version 1.6.1:

<img width="956" alt="Image" src="https://github.com/user-attachments/assets/4a576ca3-2268-45c0-8fa8-cccea16fce6d" />



### Steps/Code to Reproduce

You can reproduce it with this snippet: 

```
import numpy as np
from sklearn.decomposition import PCA

X = np.random.choice([0, 1], size=(10, 2048), p=[0.7, 0.3])
print(X.shape, X.dtype)

pca = PCA(n_components=2)
pca.fit_transform(X)
print(pca.explained_variance_ratio_)
print(pca.singular_values_)

```



### Expected Results

This works with version `1.3.2`. 

```
(10, 2048) int64
[0.12276184 0.11835199]
[21.7604452  21.36603173]
```



I tried using `svd_solver='arpack'`, but that does not help in my desperate attempts to solve the issue.  Why did this stop working after `1.3.2`?  For now, I just rolled back to `1.3.2`. 


Thanks

### Actual Results

<img width="956" alt="Image" src="https://github.com/user-attachments/assets/eaea3acd-7429-4497-9b14-b2c121fe1918" />

### Versions

```shell
Version with the error `1.6.1`. Version that works for me: `1.3.2`.
```

COMMENT:
@lesteve I feel kind of bad. Yeah, the name of `sklearnex' is in the folder name. Life is hectic this week. Thanks for catching that and closing the report. It was my bad. Best.

Labels: Bug, Needs Triage
DOC Jupyterlite raises a ValueError when using plotly

### Describe the issue linked to the documentation

Running for instance `plot_forest_hist_grad_boosting_comparison` in jupyterlite raises a `ValueError: Mime type rendering requires nbformat>=4.2.0 but it is not installed`. I tried adding `%pip install nbformat` at the top of the notebook cell but that doesn't seem to work. As per [this post in stackoverflow](https://stackoverflow.com/questions/69304838/plotly-cannot-find-nbformat-even-though-its-there-jupyter-notebook), downgrading `nbformat` to `5.1.2` solved this issue for me.

### Suggest a potential alternative/fix

Add a magic function `%pip install nbformat==5.1.2` whenever plotly is imported.

COMMENT:
I opened #31400 with a potential fix.

For further reference [link to the JupyterLite example](https://scikit-learn.org/dev/lite/lab/index.html?path=auto_examples/ensemble/plot_forest_hist_grad_boosting_comparison.ipynb)

In the last cell the figure does show up but there is an error:
![Image](https://github.com/user-attachments/assets/755690d0-083f-4851-8c35-351332bc5939)

Labels: Documentation
Avoid bundling tests in wheels

### Describe the bug

The wheels currently include tests and test data. These usually are of no additional value outside of the source distributions and thus just bloat the distribution and complicate reviews. For this reasons, I recommend excluding them from future wheels.

This matches the official recommendation for Python packaging as well (see https://packaging.python.org/en/latest/discussions/package-formats/#what-is-a-wheel):

> Wheels are meant to contain exactly what is to be installed, and nothing more. In particular, wheels should never include tests and documentation, while sdists commonly do.

### Steps/Code to Reproduce

Download the current wheels and look for `sklearn/datasets/tests`

### Expected Results

The directory is absent.

### Actual Results

The directory exists.

### Versions

```shell
1.6.1
```

COMMENT:
Could you add a bit more details why this is causing you any issue? Do you have an environment where additional size really matters? When you say it "complicate reviews", I guess you mean some kind of compliance review (basing this guess on a few issues you recently opened)?

It looks like you care about this and have [opened issues in many projects](https://github.com/search?q=author%3Astefan6419846+bundling&type=issues) so I would be curious to know more.

As a maintainer, I know I have found it convenient in the past to be able to run the tests against an installed wheel. For example upload to test.pypi.org install from test.pypi.org and double-check everything was fine by running `pytest --pyargs <my-package>`. Not sure how you would run the tests against an installed wheel if we were to remove the tests from the wheel. 

I quickly double-checked and it seems like numpy and scipy also still have tests in their wheels, although there has been some work for making it easier to produce wheels without tests: https://github.com/numpy/numpy/issues/25737.

I am marking this as "Needs Decision" for now.

Labels: Needs Decision
Avoid bundling tests in wheels

### Describe the bug

The wheels currently include tests and test data. These usually are of no additional value outside of the source distributions and thus just bloat the distribution and complicate reviews. For this reasons, I recommend excluding them from future wheels.

This matches the official recommendation for Python packaging as well (see https://packaging.python.org/en/latest/discussions/package-formats/#what-is-a-wheel):

> Wheels are meant to contain exactly what is to be installed, and nothing more. In particular, wheels should never include tests and documentation, while sdists commonly do.

### Steps/Code to Reproduce

Download the current wheels and look for `sklearn/datasets/tests`

### Expected Results

The directory is absent.

### Actual Results

The directory exists.

### Versions

```shell
1.6.1
```

COMMENT:
> Could you add a bit more details why this is causing you any issue? Do you have an environment where additional size really matters? When you say it "complicate reviews", I guess you mean some kind of compliance review (basing this guess on a few issues you recently opened)?

I do indeed care about this, yes. In this specific case, I am working on license compliance reviews for possibly integrating this into our (commercial) products. This involves a semi-automated process of basically reviewing every single file.

For packages with plain Python code and good test coverage, tests tend to be more than 50% of the actual source code. From time to time, especially test data seems to have dubious origins or other issues which complicate clean distribution. Avoiding bundling the tests inside the wheels helps cutting down the amount of work and the storage required for this. At the same time, this aligns with the PyPA recommendations on wheel builds. Usually, I as the final user do not want to run the library tests as this is part of the upstream process, although there are no warranties of course - I usually have my own integration and unit tests ensuring that updates do not break my code.

Please note that the aforementioned statistics do not hold true for *scikit-learn* directly. Some rough statistics show 459 test files (6 MB) and 517 regular files (37 MB), although you should take this with some caution due to additional files being created by unpacking archives for example. *scipy* and *numpy* are further candidates where I did not yet open a corresponding issue - their (unpacked) numbers are 1181 test files out of 1948 total files and 514 test files out of 1022 files in the current sample.

Labels: Needs Decision
Avoid bundling tests in wheels

### Describe the bug

The wheels currently include tests and test data. These usually are of no additional value outside of the source distributions and thus just bloat the distribution and complicate reviews. For this reasons, I recommend excluding them from future wheels.

This matches the official recommendation for Python packaging as well (see https://packaging.python.org/en/latest/discussions/package-formats/#what-is-a-wheel):

> Wheels are meant to contain exactly what is to be installed, and nothing more. In particular, wheels should never include tests and documentation, while sdists commonly do.

### Steps/Code to Reproduce

Download the current wheels and look for `sklearn/datasets/tests`

### Expected Results

The directory is absent.

### Actual Results

The directory exists.

### Versions

```shell
1.6.1
```

COMMENT:
We (e.g. the [cuml](https://github.com/rapids/cuml) project) rely on the bundled tests and find it useful that all you have to do is to install the version of scikit-learn you want to test against. We could of course checkout the right version from the git repository, etc but it introduces several points of failure where you could end up with tests that are from a different version than the version you have installed.

Labels: Needs Decision
Avoid bundling tests in wheels

### Describe the bug

The wheels currently include tests and test data. These usually are of no additional value outside of the source distributions and thus just bloat the distribution and complicate reviews. For this reasons, I recommend excluding them from future wheels.

This matches the official recommendation for Python packaging as well (see https://packaging.python.org/en/latest/discussions/package-formats/#what-is-a-wheel):

> Wheels are meant to contain exactly what is to be installed, and nothing more. In particular, wheels should never include tests and documentation, while sdists commonly do.

### Steps/Code to Reproduce

Download the current wheels and look for `sklearn/datasets/tests`

### Expected Results

The directory is absent.

### Actual Results

The directory exists.

### Versions

```shell
1.6.1
```

COMMENT:
Same argument as https://github.com/scikit-learn/scikit-learn/issues/31390#issuecomment-2894334747, no action here should be done IMO pending that discussion.

Labels: Needs Decision
Avoid bundling tests in wheels

### Describe the bug

The wheels currently include tests and test data. These usually are of no additional value outside of the source distributions and thus just bloat the distribution and complicate reviews. For this reasons, I recommend excluding them from future wheels.

This matches the official recommendation for Python packaging as well (see https://packaging.python.org/en/latest/discussions/package-formats/#what-is-a-wheel):

> Wheels are meant to contain exactly what is to be installed, and nothing more. In particular, wheels should never include tests and documentation, while sdists commonly do.

### Steps/Code to Reproduce

Download the current wheels and look for `sklearn/datasets/tests`

### Expected Results

The directory is absent.

### Actual Results

The directory exists.

### Versions

```shell
1.6.1
```

COMMENT:
I'd say since tests are actually used in our and third party devs CI, we don't have plans to remove them at the moment.

Labels: Needs Decision
Contains code not allowed for commercial use

### Describe the bug

https://github.com/scikit-learn/scikit-learn/blob/ff6bf36f06ca80bf505f37a8c5c42047129952ec/sklearn/datasets/_samples_generator.py#L1900 refers to code at https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py, which contains the following notice (emphasis mine):

> You are free to use, change, or redistribute the code in any way you wish for **non-commercial purposes**, but please maintain the name of the original author. This code comes with no warranty of any kind.

This might be problematic for anyone using *scikit-learn* in a commercial context.

### Steps/Code to Reproduce

Not required.

### Expected Results

The code does not restrict commercial usage hidden deeply inside the code or external references.

### Actual Results

The code restricts commercial usage hidden deeply inside an external reference.

### Versions

```shell
1.6.1 and main
```

COMMENT:
https://github.com/scikit-learn/scikit-learn/tree/main/sklearn/datasets/tests/data/openml/id_42074 uses a similar incompatible license (CC-BY-NC-SA-4.0 according to https://www.openml.org/search?type=data&sort=runs&id=42074&status=active), but this specific case might be solved by #31391 as well.

Labels: Needs Investigation
Contains code not allowed for commercial use

### Describe the bug

https://github.com/scikit-learn/scikit-learn/blob/ff6bf36f06ca80bf505f37a8c5c42047129952ec/sklearn/datasets/_samples_generator.py#L1900 refers to code at https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py, which contains the following notice (emphasis mine):

> You are free to use, change, or redistribute the code in any way you wish for **non-commercial purposes**, but please maintain the name of the original author. This code comes with no warranty of any kind.

This might be problematic for anyone using *scikit-learn* in a commercial context.

### Steps/Code to Reproduce

Not required.

### Expected Results

The code does not restrict commercial usage hidden deeply inside the code or external references.

### Actual Results

The code restricts commercial usage hidden deeply inside an external reference.

### Versions

```shell
1.6.1 and main
```

COMMENT:
`make_swiss_roll` generates a toy dataset, the code is based on a mathematical formula, that can probably fit on a single line. It doesn't look like the code was copied and pasted but inspired from it, looking at the [original code](https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py) and the first version of the [scikit-learn code](https://github.com/scikit-learn/scikit-learn/commit/032f76dec46e34f83b19c26191c348f1904dc578).

The test data one, well I am not sure. I guess that if you are installing scikit-learn in a commercial setting, technically you are making a copy of the CC-BY-NC-SA data and that's not allowed by the license? Maybe a quicker fix would be to use another test data instead ...

Even if we remove tests from wheels, they will still be included in the sdist, so I guess #31191 will not completely fix it.

By the way, I am curious, I am guessing you have some automated tools help you find this kind of issues?

Labels: Needs Investigation