Talip7/scikit-learn-issues-multilabel huggingface dataset:
BUG RidgeCV with gcv_mode="svd" is unstable when alpha is very small

### Describe the bug

As observed in this PR https://github.com/scikit-learn/scikit-learn/pull/27842#discussion_r2361459678 there is a bug with `RidgeCV`with `gcv_mode="svd"`. The problem seems to appear for very small alpha values (1e-14 or less). The other `gcv_mode="eigen"` works fine.

It's maybe related to this bug https://github.com/scikit-learn/scikit-learn/issues/26848#issuecomment-1638986852 where `alpha` is not very small but fitting is done with large `sample_weight`, again `gcv_mode="eigen"` works fine but `gcv_mode="svd"` gives diverging coefficients and very poor score.

### Steps/Code to Reproduce

```python
from sklearn.datasets import make_regression
from sklearn.linear_model import RidgeCV
from sklearn.model_selection import train_test_split

alphas = [1e-15, 1e-14]
X, y = make_regression(n_samples=1000, n_features=50, noise=0, random_state=42)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.9, random_state=42)
n_train = X_train.shape[0]
ridge_cv = RidgeCV(alphas=alphas, gcv_mode="svd")
ridge_cv.fit(X_train, y_train)
score = ridge_cv.score(X_test, y_test)
min_coef = ridge_cv.coef_.min()
max_coef = ridge_cv.coef_.max()
print(f"{score=:.2f} {min_coef=:.2f} {max_coef=:.2f}")
```

### Expected Results

We expect an also perfect fit in this case, eg `gcv_mode="eigen"` gives
```python
# score=1.00 min_coef=-0.00 max_coef=94.78
```

### Actual Results

The score is catastrophic and there is an issue with the fitted coefficients magnitude.
```python
# score=-37754.60 min_coef=-9221.16 max_coef=11981.91
```

### Versions

```shell
sklearn: 1.8.dev0
```

COMMENT:
A possible fix (using the full svd of X) is shown in the linked draft PR.

Labels: Bug, Needs Investigation, Numerical Stability
BUG RidgeCV with gcv_mode="svd" is unstable when alpha is very small

### Describe the bug

As observed in this PR https://github.com/scikit-learn/scikit-learn/pull/27842#discussion_r2361459678 there is a bug with `RidgeCV`with `gcv_mode="svd"`. The problem seems to appear for very small alpha values (1e-14 or less). The other `gcv_mode="eigen"` works fine.

It's maybe related to this bug https://github.com/scikit-learn/scikit-learn/issues/26848#issuecomment-1638986852 where `alpha` is not very small but fitting is done with large `sample_weight`, again `gcv_mode="eigen"` works fine but `gcv_mode="svd"` gives diverging coefficients and very poor score.

### Steps/Code to Reproduce

```python
from sklearn.datasets import make_regression
from sklearn.linear_model import RidgeCV
from sklearn.model_selection import train_test_split

alphas = [1e-15, 1e-14]
X, y = make_regression(n_samples=1000, n_features=50, noise=0, random_state=42)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.9, random_state=42)
n_train = X_train.shape[0]
ridge_cv = RidgeCV(alphas=alphas, gcv_mode="svd")
ridge_cv.fit(X_train, y_train)
score = ridge_cv.score(X_test, y_test)
min_coef = ridge_cv.coef_.min()
max_coef = ridge_cv.coef_.max()
print(f"{score=:.2f} {min_coef=:.2f} {max_coef=:.2f}")
```

### Expected Results

We expect an also perfect fit in this case, eg `gcv_mode="eigen"` gives
```python
# score=1.00 min_coef=-0.00 max_coef=94.78
```

### Actual Results

The score is catastrophic and there is an issue with the fitted coefficients magnitude.
```python
# score=-37754.60 min_coef=-9221.16 max_coef=11981.91
```

### Versions

```shell
sklearn: 1.8.dev0
```

COMMENT:
Ping @lorentzenchr @agramfort @josephsalmon @mathurinm in case any of you has some spare brain cycle to allocate to interesting numerical stability / linear algebra problems (see ideas explored in #32506 for a start).

Labels: Bug, Needs Investigation, Numerical Stability
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83817&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd) on Jan 01, 2026

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
I managed to reproduced the failure from [build log](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80961&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd&t=c073cbc0-0094-54ff-6a32-c70e36da1f8e) locally:
```
PARALLEL FAILED tests/test_common.py::test_estimators[GammaRegressor(max_iter=5)-check_regressor_data_not_an_array] - AssertionError:
```

For some unknown reason I had to modify the test slightly [^1]:
```diff
diff --git a/sklearn/utils/estimator_checks.py b/sklearn/utils/estimator_checks.py
index d8cd13848a0..a7375c451b2 100644
--- a/sklearn/utils/estimator_checks.py
+++ b/sklearn/utils/estimator_checks.py
@@ -3778,7 +3778,7 @@ def check_regressor_data_not_an_array(name, estimator_orig):
     X, y = _regression_dataset()
     X = _enforce_estimator_tags_X(estimator_orig, X)
     y = _enforce_estimator_tags_y(estimator_orig, y)
-    for obj_type in ["NotAnArray", "PandasDataframe"]:
+    for obj_type in ["NotAnArray"]:
         check_estimators_data_not_an_array(name, estimator_orig, X, y, obj_type)
```

[^1]: the CI error is about `_NotAnArray` and the free-threaded CI does not have pandas installed, since there is no free-threaded Python 3.14 wheel last time I checked.

I ran the tests with:
```
pytest --parallel-threads 10 --iterations 100 sklearn/tests/test_common.py -k 'GammaRegressor and data_not_an_array' 
```

The difference are quite big locally:
```
E       AssertionError: 
E       Not equal to tolerance rtol=1e-07, atol=0.01
E       GammaRegressor
E       Mismatched elements: 200 / 200 (100%)
E       Max absolute difference among violations: 1396.46228471
E       Max relative difference among violations: 0.8072651
E        ACTUAL: array([333.405986, 333.405986, 333.405986, 333.405986, 333.405986,
E              333.405986, 333.405986, 333.405986, 333.405986, 333.405986,
E              333.405986, 333.405986, 333.405986, 333.405986, 333.405986,...
E        DESIRED: array([1689.734528, 1685.315627, 1688.539379, 1674.535444, 1660.958245,
E              1689.248467, 1681.118099, 1719.871918, 1689.214872, 1689.802919,
E              1676.679989, 1716.546428, 1668.161004, 1673.188435, 1651.40503 ,...
```

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
Different one today, tests stop at 91% with a not super informative (partial?) stack-trace ... [build log](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=81224&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd&t=c073cbc0-0094-54ff-6a32-c70e36da1f8e)

```
utils/tests/test_arpack.py ············································· [ 90%]
·······················································                  [ 90%]
utils/tests/test_array_api.py ···ss·ssssssssssssssssssssssssssssssssssss [ 90%]
ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss [ 91%]
ssssssssss [QueueFeederThre] (most recent call first):
  File "/home/vsts/miniforge3/envs/testvenv/lib/python3.14t/threading.py", line 369 in wait
  File "/home/vsts/miniforge3/envs/testvenv/lib/python3.14t/site-packages/joblib/externals/loky/backend/queues.py", line 147 in _feed
  File "/home/vsts/miniforge3/envs/testvenv/lib/python3.14t/threading.py", line 1023 in run
  File "/home/vsts/miniforge3/envs/testvenv/lib/python3.14t/threading.py", line 1081 in _bootstrap_inner
  File "/home/vsts/miniforge3/envs/testvenv/lib/python3.14t/threading.py", line 1043 in _bootstrap

Thread 0x00007f0203fff640 [ExecutorManager] (most recent call first):
  File "/home/vsts/miniforge3/envs/testvenv/lib/python3.14t/selectors.py", line 398 in select
  File "/home/vsts/miniforge3/envs/testvenv/lib/python3.14t/multiprocessing/connection.py", line 1165 in wait
  File "/home/vsts/miniforge3/envs/testvenv/lib/python3.14t/site-packages/joblib/externals/loky/process_executor.py", line 681 in wait_result_broken_or_wakeup
  File "/home/vsts/miniforge3/envs/testvenv/lib/python3.14t/site-packages/joblib/externals/loky/process_executor.py", line 623 in run

```

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
Hmmm yet another one without clear symptoms [build log](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=81395&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd&t=c073cbc0-0094-54ff-6a32-c70e36da1f8e) the tests stop around 87% (after ~30 minutes so this is not a timeout)

```
······················                                                   [ 86%]
tests/test_min_dependencies_readme.py ··········                         [ 86%]
tests/test_multiclass.py ··············································· [ 87%]
············                                                             [ 87%]
tests/test_multioutput.py ··················
##[error]Bash exited with code '1'.
```

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
I think we should enable verbose test names and `pytest-timeout` (or https://github.com/pytest-dev/pytest/pull/13679 once we use a recent enough version of pytest).

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
But indeed since this last one did not reach the CI timeout, `pytest-timeout` might no help much.

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
What is weird for https://github.com/scikit-learn/scikit-learn/issues/32430#issuecomment-3404378128 is that we have no info about the main thread, only helper threads from loky. It's quite unexpected to get the main thread to die without any error message...

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
Another one without clear symptoms on October 26, tests stop around 92% [build log](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=81684&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd&t=c073cbc0-0094-54ff-6a32-c70e36da1f8e)

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
`test_graphical_lasso[95]` seen in [build log](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=82788&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd) is likely not free-threaded specific and will be fixed by https://github.com/scikit-learn/scikit-learn/pull/32757

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
Yet another one without clear symptoms, tests stop around 91% [build log](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83072&view=logs&jobId=c10228e9-6cf7-5c29-593f-d74f893ca1bd&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd&t=c073cbc0-0094-54ff-6a32-c70e36da1f8e)

```
utils/tests/test_arpack.py ············································· [ 90%]
·······················································                  [ 90%]
utils/tests/test_array_api.py ···ssssssss·ssssssssssssssssssssssssssssss [ 90%]
ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss [ 91%]
ssssssssssssssssssssssssssssssssssssss
##[error]Bash exited with code '1'.
```

I am actually wondering whether this is not our `SKLEARN_FAULTHANDLER_TIMEOUT` which is doing it since it is set to 30 minutes and the test stop around 30 minutes ... https://github.com/scikit-learn/scikit-learn/issues/32430#issuecomment-3421317849 also mentions test end after 30 minutes. Maybe the short-term work-around is to increase `SKLEARN_FAULTHANDLER_TIMEOUT` and the longer-term is https://github.com/scikit-learn/scikit-learn/pull/32776.

You would expect the faulthandler info to be in the log but maybe because of some buffering (lack of flushing) somewhere it isn't ... https://github.com/scikit-learn/scikit-learn/issues/32430#issuecomment-3404378128 shows partial stack-trace, all the other instances show no information.

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
Hmmm maybe actually `dump_traceback_later(..., exit=True)` doesn't flush stdout/stderr which is why we are seeing no or partial faulthandler info?

According to the doc: https://docs.python.org/3/library/faulthandler.html#faulthandler.dump_traceback_later 

>  If exit is True, call _exit() with status=1 after dumping the tracebacks. (Note _exit() exits the process immediately, which means it doesn’t do any cleanup like flushing file buffers.)

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Jan 03, 2026) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83868&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Jan 03, 2026)
- test_response_values_output_shape_[estimator10-predict-multiclass-expected_shape10]

COMMENT:
[December 25](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83691&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd&t=c073cbc0-0094-54ff-6a32-c70e36da1f8e) and [December 29](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=83740&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd&t=c073cbc0-0094-54ff-6a32-c70e36da1f8e&l=987) are both segmentation faults like https://github.com/scikit-learn/scikit-learn/issues/32430#issuecomment-3685142330

Labels: Bug
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:
Is there an easy way to detect that this has happened, either for a human or a bit of code? I think noticing that this happened is tricky (if you haven't recently dealt with it) and might send people down some weird side quest debugging meson/build infra.

I agree fixing it is low priority, but maybe there is a low effort thing we can do to help people spot that this has happened to them (and then manually fix it).

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:
> In practice, I think nobody noticed for a long time

I noticed it almost as soon as https://github.com/scikit-learn/scikit-learn/pull/32259 got merged. It made the tests fail because it wasn't rebuilding the cython extension.

But I'm used to make clean and make in from the before meson times when we had to do this more regularly. At the time we even had a helper that would check which cython files had been modified recently and only cythonize those when rebuilding.

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 guess the simplest work-around I can think of if you know which `.pyx` should be rebuilt is to `touch` the `.pyx` ...

Sometimes it's not that easy because a single `.pxd` maybe used in many `.pyx` sometimes I guess even transitively ...

In an ideal world we use meson built-in Cython integration as in before #31212 and I guess it would "just work". But then you have the long path issue on Windows ...

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 opened #32420 that seems to improve the situation by using Cython depfiles.

Labels: Build / CI, Low Priority