Talip7/scikit-learn-issues-multilabel huggingface dataset:
Problem in our `meson.build` files: modifying a `.pxd` does not rebuild the associated shared library

When you touch a `.pxd` it doesn't cythonize the associated `.pyx` and doesn't rebuild the associated shared library (`.so` on Linux) which is wrong.

For example when in meson editable mode:
```
touch sklearn/tree/_partitioner.pxd
python -c "import sklearn"
```

I would expect `sklearn/tree/_partitioner.pyx` to be turned into a `.c` file and then the `sklearn.tree/_partitioner.so` to be generated but nothing is rebuilt.

I think it's an unforunate side-effect of https://github.com/scikit-learn/scikit-learn/pull/31212 because we are using custom meson generator rather than built-in meson Cython integration to avoid long generated paths which may be a problem on Windows.

I would need to think a bit more about what is the best way forward ideally meson would deal with long paths  ... 

As a stop gap solution, we could follow what scipy is doing by defining all the dependencies manually, but this is a bit cumbersome see e.g. https://github.com/scipy/scipy/blob/2ee4675fb1d1cfe70828cfc287e6078b33d8be72/scipy/linalg/meson.build#L40-L43

In practice, I think nobody noticed for a long time, until we started modifying many Cython files at once in #32315. Basically I am not in a hurry to fix this, but anyone should feel free to voice a different opinion 😉.

COMMENT:
I confirm that the issues I reported are now fixed! 🎉 Thanks a lot, that will be helpful!

Labels: Build / CI, Low Priority
Problem in our `meson.build` files: modifying a `.pxd` does not rebuild the associated shared library

When you touch a `.pxd` it doesn't cythonize the associated `.pyx` and doesn't rebuild the associated shared library (`.so` on Linux) which is wrong.

For example when in meson editable mode:
```
touch sklearn/tree/_partitioner.pxd
python -c "import sklearn"
```

I would expect `sklearn/tree/_partitioner.pyx` to be turned into a `.c` file and then the `sklearn.tree/_partitioner.so` to be generated but nothing is rebuilt.

I think it's an unforunate side-effect of https://github.com/scikit-learn/scikit-learn/pull/31212 because we are using custom meson generator rather than built-in meson Cython integration to avoid long generated paths which may be a problem on Windows.

I would need to think a bit more about what is the best way forward ideally meson would deal with long paths  ... 

As a stop gap solution, we could follow what scipy is doing by defining all the dependencies manually, but this is a bit cumbersome see e.g. https://github.com/scipy/scipy/blob/2ee4675fb1d1cfe70828cfc287e6078b33d8be72/scipy/linalg/meson.build#L40-L43

In practice, I think nobody noticed for a long time, until we started modifying many Cython files at once in #32315. Basically I am not in a hurry to fix this, but anyone should feel free to voice a different opinion 😉.

COMMENT:
> I confirm that the issues I reported are now fixed! 🎉 Thanks a lot, that will be helpful!

Glad to hear that 🙏!

Labels: Build / CI, Low Priority
Make `make_classification` draw from the same distribution regardless of `n_samples`

### Describe the workflow you want to enable

I would expect the following code to output two different samplings of the same distribution:
```python
import matplotlib.pyplot as plt
from sklearn.datasets import make_classification

common_params = {
    "n_features": 2,
    "n_informative": 2,
    "n_redundant": 0,
    "random_state": 0,
}

# Generate two datasets with different sample sizes
X1, y1 = make_classification(n_samples=200, **common_params)
X2, y2 = make_classification(n_samples=500, **common_params)

fig, axes = plt.subplots(1, 2, figsize=(10, 4), sharex=True, sharey=True)

axes[0].scatter(X1[:, 0], X1[:, 1], c=y1)
axes[0].set_title("n_samples = 200")

axes[1].scatter(X2[:, 0], X2[:, 1], c=y2)
axes[1].set_title("n_samples = 500")

for ax in axes:
    ax.set_xlabel("Feature 1")
    ax.set_ylabel("Feature 2")
plt.show()
```

Actual output:

<img width="844" height="391" alt="Image" src="https://github.com/user-attachments/assets/b8a9b5b6-ea41-4049-9f73-e15b2b3c8cc1" />

### Describe your proposed solution

Construct A and B transformations in
https://github.com/scikit-learn/scikit-learn/blob/3498b6f2958839b5e89f21dcefc67ceb72de589c/sklearn/datasets/_samples_generator.py#L291-L306
and precompute the indices in
https://github.com/scikit-learn/scikit-learn/blob/3498b6f2958839b5e89f21dcefc67ceb72de589c/sklearn/datasets/_samples_generator.py#L311
such that the actual `standard_normal` draw of `n_samples` is delayed as much as possible.

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

An alternative is setting a fixed private `random_state` only for drawing samples, whereas the user can control the rest via the exposed `random_state`.

### Additional context

I opened #32406 to address the issue from a documentation point of view for the moment.

COMMENT:
Hi @ArturoAmorQ 👋,

Thank you for this fantastic and well-documented issue report! The reproducible example made it very clear to understand.

I've worked on a fix following your suggested approach. The implementation now decouples the generation of the distribution's structural parameters (like the cluster transformation matrices A and B) from the generation of the actual samples. This ensures that for a given random_state, the underlying distribution remains consistent, regardless of n_samples.

Here’s a screenshot showing the corrected output from your example script:

<img width="1243" height="581" alt="Image" src="https://github.com/user-attachments/assets/b7d06cc9-e9ea-424f-b11c-843199bd4710" />

As you can see, the clusters are now in the same position and have the same orientation, with only the number of points changing.

The local tests are passing, and I'll be opening a Pull Request for review shortly. Cheers!

Labels: New Feature, module:datasets
Make `make_classification` draw from the same distribution regardless of `n_samples`

### Describe the workflow you want to enable

I would expect the following code to output two different samplings of the same distribution:
```python
import matplotlib.pyplot as plt
from sklearn.datasets import make_classification

common_params = {
    "n_features": 2,
    "n_informative": 2,
    "n_redundant": 0,
    "random_state": 0,
}

# Generate two datasets with different sample sizes
X1, y1 = make_classification(n_samples=200, **common_params)
X2, y2 = make_classification(n_samples=500, **common_params)

fig, axes = plt.subplots(1, 2, figsize=(10, 4), sharex=True, sharey=True)

axes[0].scatter(X1[:, 0], X1[:, 1], c=y1)
axes[0].set_title("n_samples = 200")

axes[1].scatter(X2[:, 0], X2[:, 1], c=y2)
axes[1].set_title("n_samples = 500")

for ax in axes:
    ax.set_xlabel("Feature 1")
    ax.set_ylabel("Feature 2")
plt.show()
```

Actual output:

<img width="844" height="391" alt="Image" src="https://github.com/user-attachments/assets/b8a9b5b6-ea41-4049-9f73-e15b2b3c8cc1" />

### Describe your proposed solution

Construct A and B transformations in
https://github.com/scikit-learn/scikit-learn/blob/3498b6f2958839b5e89f21dcefc67ceb72de589c/sklearn/datasets/_samples_generator.py#L291-L306
and precompute the indices in
https://github.com/scikit-learn/scikit-learn/blob/3498b6f2958839b5e89f21dcefc67ceb72de589c/sklearn/datasets/_samples_generator.py#L311
such that the actual `standard_normal` draw of `n_samples` is delayed as much as possible.

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

An alternative is setting a fixed private `random_state` only for drawing samples, whereas the user can control the rest via the exposed `random_state`.

### Additional context

I opened #32406 to address the issue from a documentation point of view for the moment.

COMMENT:
Hey @ArturoAmorQ ! I see it's been 3 weeks since this issue was opened and there hasn't been a merge till now, so is it fine if I take up this issue?

Labels: New Feature, module:datasets
Make `make_classification` draw from the same distribution regardless of `n_samples`

### Describe the workflow you want to enable

I would expect the following code to output two different samplings of the same distribution:
```python
import matplotlib.pyplot as plt
from sklearn.datasets import make_classification

common_params = {
    "n_features": 2,
    "n_informative": 2,
    "n_redundant": 0,
    "random_state": 0,
}

# Generate two datasets with different sample sizes
X1, y1 = make_classification(n_samples=200, **common_params)
X2, y2 = make_classification(n_samples=500, **common_params)

fig, axes = plt.subplots(1, 2, figsize=(10, 4), sharex=True, sharey=True)

axes[0].scatter(X1[:, 0], X1[:, 1], c=y1)
axes[0].set_title("n_samples = 200")

axes[1].scatter(X2[:, 0], X2[:, 1], c=y2)
axes[1].set_title("n_samples = 500")

for ax in axes:
    ax.set_xlabel("Feature 1")
    ax.set_ylabel("Feature 2")
plt.show()
```

Actual output:

<img width="844" height="391" alt="Image" src="https://github.com/user-attachments/assets/b8a9b5b6-ea41-4049-9f73-e15b2b3c8cc1" />

### Describe your proposed solution

Construct A and B transformations in
https://github.com/scikit-learn/scikit-learn/blob/3498b6f2958839b5e89f21dcefc67ceb72de589c/sklearn/datasets/_samples_generator.py#L291-L306
and precompute the indices in
https://github.com/scikit-learn/scikit-learn/blob/3498b6f2958839b5e89f21dcefc67ceb72de589c/sklearn/datasets/_samples_generator.py#L311
such that the actual `standard_normal` draw of `n_samples` is delayed as much as possible.

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

An alternative is setting a fixed private `random_state` only for drawing samples, whereas the user can control the rest via the exposed `random_state`.

### Additional context

I opened #32406 to address the issue from a documentation point of view for the moment.

COMMENT:
Hi @Zrahay thanks for your interest in contributing! There's already #32476 addressing the issue, it only seems we lack reviewer time. If you feel like helping, you can comment on that PR.

Labels: New Feature, module:datasets
Make `make_classification` draw from the same distribution regardless of `n_samples`

### Describe the workflow you want to enable

I would expect the following code to output two different samplings of the same distribution:
```python
import matplotlib.pyplot as plt
from sklearn.datasets import make_classification

common_params = {
    "n_features": 2,
    "n_informative": 2,
    "n_redundant": 0,
    "random_state": 0,
}

# Generate two datasets with different sample sizes
X1, y1 = make_classification(n_samples=200, **common_params)
X2, y2 = make_classification(n_samples=500, **common_params)

fig, axes = plt.subplots(1, 2, figsize=(10, 4), sharex=True, sharey=True)

axes[0].scatter(X1[:, 0], X1[:, 1], c=y1)
axes[0].set_title("n_samples = 200")

axes[1].scatter(X2[:, 0], X2[:, 1], c=y2)
axes[1].set_title("n_samples = 500")

for ax in axes:
    ax.set_xlabel("Feature 1")
    ax.set_ylabel("Feature 2")
plt.show()
```

Actual output:

<img width="844" height="391" alt="Image" src="https://github.com/user-attachments/assets/b8a9b5b6-ea41-4049-9f73-e15b2b3c8cc1" />

### Describe your proposed solution

Construct A and B transformations in
https://github.com/scikit-learn/scikit-learn/blob/3498b6f2958839b5e89f21dcefc67ceb72de589c/sklearn/datasets/_samples_generator.py#L291-L306
and precompute the indices in
https://github.com/scikit-learn/scikit-learn/blob/3498b6f2958839b5e89f21dcefc67ceb72de589c/sklearn/datasets/_samples_generator.py#L311
such that the actual `standard_normal` draw of `n_samples` is delayed as much as possible.

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

An alternative is setting a fixed private `random_state` only for drawing samples, whereas the user can control the rest via the exposed `random_state`.

### Additional context

I opened #32406 to address the issue from a documentation point of view for the moment.

COMMENT:
@KoolDrip From your screenshot, it seems that the class labels are being miss-assigned.

Labels: New Feature, module:datasets
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/20671937010) on Jan 03, 2026

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
Yeah so as kind of expected this is not determistic, the next run worked just fine ...

I guess let's keep this one open to see what happens tomorrow. Edit: the run on October 7 also worked fine.

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
Indeed, the tracebacks seem to indicate that the CPython 3.13t `warnings` module is the culprit. Hopefully, end users caring about free-threading are likely to use 3.14 once out tomorrow and will therefore not be impacted.

Since it's a bit annoying to have such "won't fix" transient crashes on our CI.

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
> Since it's a bit annoying to have such "won't fix" transient crashes on our CI.

We can remove the Python 3.13 free-threaded wheel for Windows arm64 if it starts happening too often. I guess this is what you meant to say even if you did not finish your sentence 😉.

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
I propose we keep this issue open until say mid-October to collect the Wheels CI results in the same issue and make it easier to estimate how often the Windows arm64 Python 3.13 free-threaded CI fails. We can then reassess what we want to do:
- not produce any Windows arm64 Python 3.13 free-threaded wheels if CI fails too often
- accept the flakiness of the CI if failure is rare enough

So far, the failure rate on Windows arm64 Python 3.13 free-threaded is ~1 failure over 3 runs~. Update: 1 failure over 13 runs (October 13th).

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
There is another free-threaded intermittent failure in Linux arm cp313t [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/18301431097/job/52110098521):
```
FAILED ensemble/_hist_gradient_boosting/tests/test_gradient_boosting.py::test_no_user_warning_with_scoring
```

A similar one was seen in Linux x86-64 cp313t https://github.com/scikit-learn/scikit-learn/issues/32303#issuecomment-3354667463.

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
@lesteve 
No. I have to seen this issue before, I can analyse and come back in a day or two with some understanding.

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
Windows arm today same as https://github.com/scikit-learn/scikit-learn/issues/32393#issuecomment-3396312539 again (Python 3.12 this time) [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/18581815179/job/52978194317)

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
Same failure as yesterday `ValueError: concurrent send_bytes() calls are not supported` on Windows arm `cp314t`

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
Latest failure is a cp313t intermittent failure that was already seen at least once, I opened https://github.com/scikit-learn/scikit-learn/issues/32631 to track it.

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
Another failure issue on Windows arm64 `cp314t` `ValueError: concurrent send_bytes() calls are not supported` [build log](https://github.com/scikit-learn/scikit-learn/issues/30810) https://github.com/scikit-learn/scikit-learn/issues/30810

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
All wheels are broken since November 9, ~probably some array API related PR that was merged.~ 

Hmmm it looks like a thing in pytest 9.0 with `raise unittest.case.SkipTest` https://github.com/pytest-dev/pytest/issues/13895.

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
November 21: Another Windows amd64 `cp313t` `ValueError: concurrent send_bytes() calls are not supported` https://github.com/scikit-learn/scikit-learn/issues/30810, see [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/19559347005/job/56008513439)

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
Another https://github.com/scikit-learn/scikit-learn/issues/32631 on November 22 `cp313t` Linux arm.

```
UserWarning: `sklearn.utils.parallel.delayed` should be used with `sklearn.utils.parallel.Parallel` to make it possible to propagate the scikit-learn configuration of the current thread to the joblib workers
```

[build log](https://github.com/scikit-learn/scikit-learn/actions/runs/19589859558/job/56106156587)

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
November 27: Another `ValueError: concurrent send_bytes() calls are not supported` on Windows arm cp314t https://github.com/scikit-learn/scikit-learn/issues/30810 see [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/19724629087/job/56513737010)

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
November 29: another `ValueError: concurrent send_bytes() calls are not supported` on Windows arm cp314t #30810 see [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/19778571927/job/56675393125)

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
December 1, `ValueError: concurrent send_bytes() calls are not supported` on Windows arm cp313t #30810 see [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/19810864883/job/56753112967)

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
December 3, `ValueError: concurrent send_bytes() calls are not supported` on Windows arm `cp314t` #30810 see [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/19881809388/job/56981251806)

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
December 9, `UserWarning: `sklearn.utils.parallel.delayed` should be used with `sklearn.utils.parallel.Parallel` to make it possible to propagate the scikit-learn configuration of the current thread to the joblib workers.` macOS x86_64 cp313t [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/20051369009/job/57507986633) https://github.com/scikit-learn/scikit-learn/issues/32631

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
December 17: macOS x86_64 cp313t failure without the full log for some weird reason [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/20291104247/job/58275603588)

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
December 22: ``UserWarning: `sklearn.utils.parallel.delayed` should be used with `sklearn.utils.parallel.Parallel` to make it possible to propagate the scikit-learn configuration of the current thread to the joblib workers.`` macOS x86_64 #32631 [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/20421349764/job/58673739924)

Labels: Bug
⚠️ CI failed on Wheel builder (last failure: Dec 26, 2025) ⚠️

**CI is still failing on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/20515594700)** (Dec 26, 2025)

COMMENT:
December 23: `ValueError: concurrent send_bytes() calls are not supported` Windows amd64 cp314t https://github.com/scikit-learn/scikit-learn/issues/30810 [build log](https://github.com/scikit-learn/scikit-learn/actions/runs/20450973655/job/58763923609)

Labels: Bug
[FEAT] Enhancing decision trees

### Describe the workflow you want to enable

I'd like the decision tree to be capable at capturing more complex interactions.

### Describe your proposed solution

Include new parameters:
- A global maximum gain threshold.
- A secondary threshold where if no splits are available due to the max gain threshold, and if all values exceed this 2nd threshold, use the lowest gain available, otherwise it becomes a leaf node.

This would be in contrast with the minimum impurity reduction threshold, and should encourage the tree to learn more complex interactions.

It would be more ideal if the minimum and maximum thresholds were also configurable per-feature, but that'd be going overboard.

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

_No response_

### Additional context

_No response_

COMMENT:
Hello! I would like to work on this issue. I have read the description and the contribution guidelines.

Could you please assign it to me? Thank you!

Labels: New Feature, Needs Decision