Talip7/scikit-learn-issues-multilabel huggingface dataset:
RFC Deprecate FeatureUnion and make_union

Unless I'm missing something, to me `FeatureUnion` is just a `ColumnTransformer` where all transformers are applied to all features. So it's just a special case of `ColumnTransformer`.

```py
import pandas as pd
from sklearn.pipeline import FeatureUnion
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler

df = pd.DataFrame({"a": [1, 2, 3, 4], "b": [1, 2, 3, 4]})

fu = FeatureUnion([("std_1", StandardScaler()), ("std_2", StandardScaler())])
fu.set_output(transform="pandas")
print(fu.fit_transform(df))
   std_1__a  std_1__b  std_2__a  std_2__b
0 -1.341641 -1.341641 -1.341641 -1.341641
1 -0.447214 -0.447214 -0.447214 -0.447214
2  0.447214  0.447214  0.447214  0.447214
3  1.341641  1.341641  1.341641  1.341641

all_cols = slice(None)
ct = ColumnTransformer([("std_1", StandardScaler(), all_cols), ("std_2", StandardScaler(), all_cols)])
ct.set_output(transform="pandas")
print(ct.fit_transform(df))
   std_1__a  std_1__b  std_2__a  std_2__b
0 -1.341641 -1.341641 -1.341641 -1.341641
1 -0.447214 -0.447214 -0.447214 -0.447214
2  0.447214  0.447214  0.447214  0.447214
3  1.341641  1.341641  1.341641  1.341641
```

In addition, the parameters of `FeatureUnion` is a subset of the parameters of `ColumnTransformer`, so I don't see anything that one would be able to do with `FeatureUnion` but not with `ColumnTransformer`.

From a maintenance view, it duplicates the burden because they share almost no code and it's common that they suffer from the same bugs and  fixes have to be repeated in both classes. And usually one or the other keeps the bug for a while because we only implement a fix for one and forget about the other. In general the forgotten one is `FeatureUnion` btw :) (e.g. the latest one https://github.com/scikit-learn/scikit-learn/issues/32104 for `FeatureUnion` that was detected and fixed a while ago for `ColumnTransformer` https://github.com/scikit-learn/scikit-learn/issues/28260)

Finally, `FeatureUnion` has unresolved long standing issues like not cloning the transformers before fitting and modifying init parameters during fit, meaning that it does not follow our Transformer API.

Considering all that, I propose to deprecate `FeatureUnion`.

ping @scikit-learn/core-devs, did I miss something obvious ? what's your opinion about that ?

COMMENT:
What about the Zen of Python/PEP 20?

Labels: API, RFC, module:compose, module:pipeline
RFC Deprecate FeatureUnion and make_union

Unless I'm missing something, to me `FeatureUnion` is just a `ColumnTransformer` where all transformers are applied to all features. So it's just a special case of `ColumnTransformer`.

```py
import pandas as pd
from sklearn.pipeline import FeatureUnion
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler

df = pd.DataFrame({"a": [1, 2, 3, 4], "b": [1, 2, 3, 4]})

fu = FeatureUnion([("std_1", StandardScaler()), ("std_2", StandardScaler())])
fu.set_output(transform="pandas")
print(fu.fit_transform(df))
   std_1__a  std_1__b  std_2__a  std_2__b
0 -1.341641 -1.341641 -1.341641 -1.341641
1 -0.447214 -0.447214 -0.447214 -0.447214
2  0.447214  0.447214  0.447214  0.447214
3  1.341641  1.341641  1.341641  1.341641

all_cols = slice(None)
ct = ColumnTransformer([("std_1", StandardScaler(), all_cols), ("std_2", StandardScaler(), all_cols)])
ct.set_output(transform="pandas")
print(ct.fit_transform(df))
   std_1__a  std_1__b  std_2__a  std_2__b
0 -1.341641 -1.341641 -1.341641 -1.341641
1 -0.447214 -0.447214 -0.447214 -0.447214
2  0.447214  0.447214  0.447214  0.447214
3  1.341641  1.341641  1.341641  1.341641
```

In addition, the parameters of `FeatureUnion` is a subset of the parameters of `ColumnTransformer`, so I don't see anything that one would be able to do with `FeatureUnion` but not with `ColumnTransformer`.

From a maintenance view, it duplicates the burden because they share almost no code and it's common that they suffer from the same bugs and  fixes have to be repeated in both classes. And usually one or the other keeps the bug for a while because we only implement a fix for one and forget about the other. In general the forgotten one is `FeatureUnion` btw :) (e.g. the latest one https://github.com/scikit-learn/scikit-learn/issues/32104 for `FeatureUnion` that was detected and fixed a while ago for `ColumnTransformer` https://github.com/scikit-learn/scikit-learn/issues/28260)

Finally, `FeatureUnion` has unresolved long standing issues like not cloning the transformers before fitting and modifying init parameters during fit, meaning that it does not follow our Transformer API.

Considering all that, I propose to deprecate `FeatureUnion`.

ping @scikit-learn/core-devs, did I miss something obvious ? what's your opinion about that ?

COMMENT:
It may not be obvious at first, but I am Dutch.

Labels: API, RFC, module:compose, module:pipeline
RFC Deprecate FeatureUnion and make_union

Unless I'm missing something, to me `FeatureUnion` is just a `ColumnTransformer` where all transformers are applied to all features. So it's just a special case of `ColumnTransformer`.

```py
import pandas as pd
from sklearn.pipeline import FeatureUnion
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler

df = pd.DataFrame({"a": [1, 2, 3, 4], "b": [1, 2, 3, 4]})

fu = FeatureUnion([("std_1", StandardScaler()), ("std_2", StandardScaler())])
fu.set_output(transform="pandas")
print(fu.fit_transform(df))
   std_1__a  std_1__b  std_2__a  std_2__b
0 -1.341641 -1.341641 -1.341641 -1.341641
1 -0.447214 -0.447214 -0.447214 -0.447214
2  0.447214  0.447214  0.447214  0.447214
3  1.341641  1.341641  1.341641  1.341641

all_cols = slice(None)
ct = ColumnTransformer([("std_1", StandardScaler(), all_cols), ("std_2", StandardScaler(), all_cols)])
ct.set_output(transform="pandas")
print(ct.fit_transform(df))
   std_1__a  std_1__b  std_2__a  std_2__b
0 -1.341641 -1.341641 -1.341641 -1.341641
1 -0.447214 -0.447214 -0.447214 -0.447214
2  0.447214  0.447214  0.447214  0.447214
3  1.341641  1.341641  1.341641  1.341641
```

In addition, the parameters of `FeatureUnion` is a subset of the parameters of `ColumnTransformer`, so I don't see anything that one would be able to do with `FeatureUnion` but not with `ColumnTransformer`.

From a maintenance view, it duplicates the burden because they share almost no code and it's common that they suffer from the same bugs and  fixes have to be repeated in both classes. And usually one or the other keeps the bug for a while because we only implement a fix for one and forget about the other. In general the forgotten one is `FeatureUnion` btw :) (e.g. the latest one https://github.com/scikit-learn/scikit-learn/issues/32104 for `FeatureUnion` that was detected and fixed a while ago for `ColumnTransformer` https://github.com/scikit-learn/scikit-learn/issues/28260)

Finally, `FeatureUnion` has unresolved long standing issues like not cloning the transformers before fitting and modifying init parameters during fit, meaning that it does not follow our Transformer API.

Considering all that, I propose to deprecate `FeatureUnion`.

ping @scikit-learn/core-devs, did I miss something obvious ? what's your opinion about that ?

COMMENT:
> It may not be obvious at first, but I am Dutch.

Not obvious but well known😄
I wanted to stress the following:
- We have 2 classes doing almost the same thing. FestureUnion is a subset of functionalty of ColumnTransformer. So we g/should get rid of one.
- I agree that certain framework-like composition of pipelines has its appeal, but
  - out of scope of this issue
  - personal feeling is 😢😢😢 as linear models are still a pain to construct (cause of the lack of expressions/formulae inside the construction of estimators) but see point above.

So far, the most convincing to me is
> okay with deprecating, but only actually removing it in 2.0

Labels: API, RFC, module:compose, module:pipeline
RFC Deprecate FeatureUnion and make_union

Unless I'm missing something, to me `FeatureUnion` is just a `ColumnTransformer` where all transformers are applied to all features. So it's just a special case of `ColumnTransformer`.

```py
import pandas as pd
from sklearn.pipeline import FeatureUnion
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler

df = pd.DataFrame({"a": [1, 2, 3, 4], "b": [1, 2, 3, 4]})

fu = FeatureUnion([("std_1", StandardScaler()), ("std_2", StandardScaler())])
fu.set_output(transform="pandas")
print(fu.fit_transform(df))
   std_1__a  std_1__b  std_2__a  std_2__b
0 -1.341641 -1.341641 -1.341641 -1.341641
1 -0.447214 -0.447214 -0.447214 -0.447214
2  0.447214  0.447214  0.447214  0.447214
3  1.341641  1.341641  1.341641  1.341641

all_cols = slice(None)
ct = ColumnTransformer([("std_1", StandardScaler(), all_cols), ("std_2", StandardScaler(), all_cols)])
ct.set_output(transform="pandas")
print(ct.fit_transform(df))
   std_1__a  std_1__b  std_2__a  std_2__b
0 -1.341641 -1.341641 -1.341641 -1.341641
1 -0.447214 -0.447214 -0.447214 -0.447214
2  0.447214  0.447214  0.447214  0.447214
3  1.341641  1.341641  1.341641  1.341641
```

In addition, the parameters of `FeatureUnion` is a subset of the parameters of `ColumnTransformer`, so I don't see anything that one would be able to do with `FeatureUnion` but not with `ColumnTransformer`.

From a maintenance view, it duplicates the burden because they share almost no code and it's common that they suffer from the same bugs and  fixes have to be repeated in both classes. And usually one or the other keeps the bug for a while because we only implement a fix for one and forget about the other. In general the forgotten one is `FeatureUnion` btw :) (e.g. the latest one https://github.com/scikit-learn/scikit-learn/issues/32104 for `FeatureUnion` that was detected and fixed a while ago for `ColumnTransformer` https://github.com/scikit-learn/scikit-learn/issues/28260)

Finally, `FeatureUnion` has unresolved long standing issues like not cloning the transformers before fitting and modifying init parameters during fit, meaning that it does not follow our Transformer API.

Considering all that, I propose to deprecate `FeatureUnion`.

ping @scikit-learn/core-devs, did I miss something obvious ? what's your opinion about that ?

COMMENT:
Heard of [formulaic](https://matthewwardrop.github.io/formulaic/latest/), [scikit-lego](https://koaning.github.io/scikit-lego/user-guide/preprocessing/#formulaic-wilkinson-formulas) has a transformer for you!

Labels: API, RFC, module:compose, module:pipeline
Add inner max_iter or a smart automatic setting to Lasso inside graphical lasso

`GraphicalLasso` and `GraphicalLassoCV` expose `enet_tol`. They should also expose `enet_max_iter`.
Currently, the `max_iter` of the *outer iteration* is also used for this inner iteration. This is unfortunate, e.g., if you set a small number of outer iterations.

Popped up in https://github.com/scikit-learn/scikit-learn/pull/31987#discussion_r2324154906.

COMMENT:
Hi, I’m new to open source and would like to work on this issue. 
I plan to add an enet_max_iter parameter to GraphicalLasso and GraphicalLassoCV. 
I hope that’s okay!

Labels: Enhancement, API, Needs Decision, module:covariance, module:linear_model
Add inner max_iter or a smart automatic setting to Lasso inside graphical lasso

`GraphicalLasso` and `GraphicalLassoCV` expose `enet_tol`. They should also expose `enet_max_iter`.
Currently, the `max_iter` of the *outer iteration* is also used for this inner iteration. This is unfortunate, e.g., if you set a small number of outer iterations.

Popped up in https://github.com/scikit-learn/scikit-learn/pull/31987#discussion_r2324154906.

COMMENT:
Hi @lorentzenchr,

I noticed it’s been a few weeks since the previous contributor expressed interest. I’d like to help move this forward and work on adding the enet_max_iter parameter to GraphicalLasso and GraphicalLassoCV.

My approach will be to update the classes to accept this parameter and pass it to the inner Lasso solver, with corresponding updates to documentation and tests to ensure correct behavior.

Would it be okay if I take this on?

Labels: Enhancement, API, Needs Decision, module:covariance, module:linear_model
Add inner max_iter or a smart automatic setting to Lasso inside graphical lasso

`GraphicalLasso` and `GraphicalLassoCV` expose `enet_tol`. They should also expose `enet_max_iter`.
Currently, the `max_iter` of the *outer iteration* is also used for this inner iteration. This is unfortunate, e.g., if you set a small number of outer iterations.

Popped up in https://github.com/scikit-learn/scikit-learn/pull/31987#discussion_r2324154906.

COMMENT:
I will try to implement this Enhancement.

Labels: Enhancement, API, Needs Decision, module:covariance, module:linear_model
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Sep 27, 2025) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80471&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Sep 27, 2025)
- test_get_metadata_routing_without_fit[StackingClassifier-ConsumingClassifier]

COMMENT:
One of this pesky joblib `ShutdownExecutorError`, in my experience they can not be reproduced in isolation, see https://github.com/scikit-learn/scikit-learn/pull/30041#issuecomment-3175541336. Underlying issue is https://github.com/joblib/loky/issues/458. For further reference the error was:
```
PARALLEL FAILED neighbors/tests/test_kd_tree.py::test_kdtree_picklable_with_joblib[KDTree64] - joblib.externals.loky.process_executor.ShutdownExecutorError: cannot schedu...
```

We may want to leave this issue open to see how often they happen and whether it is worth doing anything about it ...

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Sep 27, 2025) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80471&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Sep 27, 2025)
- test_get_metadata_routing_without_fit[StackingClassifier-ConsumingClassifier]

COMMENT:
## CI is no longer failing! ✅

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

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Sep 27, 2025) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80471&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Sep 27, 2025)
- test_get_metadata_routing_without_fit[StackingClassifier-ConsumingClassifier]

COMMENT:
I ran the CI again for the 403 error in https://github.com/scikit-learn/scikit-learn/issues/32086, which also ran the job failing here. The new run did not fail. So definitely not 100% reproducible

Labels: Bug
⚠️ CI failed on Linux_free_threaded.pylatest_free_threaded (last failure: Sep 27, 2025) ⚠️

**CI is still failing on [Linux_free_threaded.pylatest_free_threaded](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=80471&view=logs&j=c10228e9-6cf7-5c29-593f-d74f893ca1bd)** (Sep 27, 2025)
- test_get_metadata_routing_without_fit[StackingClassifier-ConsumingClassifier]

COMMENT:
Interesting approach 😉, I never thought about rerunning the CI, I always thought "let's keep this open and see what happens tomorrow"

Labels: Bug
⚠️ CI failed on Linux_Runs.pylatest_conda_forge_mkl (last failure: Sep 03, 2025) ⚠️

**CI failed on [Linux_Runs.pylatest_conda_forge_mkl](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=79590&view=logs&j=dde5042c-7464-5d47-9507-31bdd2ee0a3a)** (Sep 03, 2025)
- Test Collection Failure

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=79590&view=logs&j=de937867-5818-5907-5645-0b22541236da) on Sep 03, 2025

Labels: Needs Triage
1.1.8 LARS Lasso at Mathematical Formulation

### Describe the issue linked to the documentation

Instead of giving a vector result, the LARS solution consists of a curve denoting the solution for each value of the l1 norm of the parameter vector.

* not a curve
* "curve" is not computed at every point
* infinitely many solutions of the l1 norm of the parameter vector

### Suggest a potential alternative/fix

Instead of returning one vector of parameters, the LARS solution returns the 2D array coef_path_ of shape (n_features, max_features + 1). The values within the 2D array are the parameters of the model at each critical point on the path drawn by the l1 norm as the alpha parameter is decreased. The first column is always zero.

Might not be the clearest either tbh, you guys can probably come up with something much nicer.

COMMENT:
Hi @AhmetVCetin04, can you clarify what you mean by "the LARS solution" ? To what method or attribute are you referring ?
If you look at the documentation of [Lars](https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.Lars.html) (same for LassoLars), there's a fitted_attribute `coef_path_` that is exactly what you're proposing I think, see [here](https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.Lars.html#:~:text=coef_path_,-array-like).

Labels: Documentation
1.1.8 LARS Lasso at Mathematical Formulation

### Describe the issue linked to the documentation

Instead of giving a vector result, the LARS solution consists of a curve denoting the solution for each value of the l1 norm of the parameter vector.

* not a curve
* "curve" is not computed at every point
* infinitely many solutions of the l1 norm of the parameter vector

### Suggest a potential alternative/fix

Instead of returning one vector of parameters, the LARS solution returns the 2D array coef_path_ of shape (n_features, max_features + 1). The values within the 2D array are the parameters of the model at each critical point on the path drawn by the l1 norm as the alpha parameter is decreased. The first column is always zero.

Might not be the clearest either tbh, you guys can probably come up with something much nicer.

COMMENT:
This should be from the userguide. And your question is exactly my point, the userguide is very unclear in mentioning what exactly it's talking about when referencing "the LARS solution." It probably is referring to the coef_path_ attribute but I am uncertain.

Labels: Documentation
1.1.8 LARS Lasso at Mathematical Formulation

### Describe the issue linked to the documentation

Instead of giving a vector result, the LARS solution consists of a curve denoting the solution for each value of the l1 norm of the parameter vector.

* not a curve
* "curve" is not computed at every point
* infinitely many solutions of the l1 norm of the parameter vector

### Suggest a potential alternative/fix

Instead of returning one vector of parameters, the LARS solution returns the 2D array coef_path_ of shape (n_features, max_features + 1). The values within the 2D array are the parameters of the model at each critical point on the path drawn by the l1 norm as the alpha parameter is decreased. The first column is always zero.

Might not be the clearest either tbh, you guys can probably come up with something much nicer.

COMMENT:
Usually solution refers to the solution of the optimization algorithm. In linear models it means the fitted coefficients of the model (i.e. the `coef_` attribute). I'm not sure how to improve the documentation, but feel free to open a PR if you want to propose something 👍

Labels: Documentation
1.1.8 LARS Lasso at Mathematical Formulation

### Describe the issue linked to the documentation

Instead of giving a vector result, the LARS solution consists of a curve denoting the solution for each value of the l1 norm of the parameter vector.

* not a curve
* "curve" is not computed at every point
* infinitely many solutions of the l1 norm of the parameter vector

### Suggest a potential alternative/fix

Instead of returning one vector of parameters, the LARS solution returns the 2D array coef_path_ of shape (n_features, max_features + 1). The values within the 2D array are the parameters of the model at each critical point on the path drawn by the l1 norm as the alpha parameter is decreased. The first column is always zero.

Might not be the clearest either tbh, you guys can probably come up with something much nicer.

COMMENT:
I would like to work on this documentation fix. Can I be assigned to this issue?

Labels: Documentation
1.1.8 LARS Lasso at Mathematical Formulation

### Describe the issue linked to the documentation

Instead of giving a vector result, the LARS solution consists of a curve denoting the solution for each value of the l1 norm of the parameter vector.

* not a curve
* "curve" is not computed at every point
* infinitely many solutions of the l1 norm of the parameter vector

### Suggest a potential alternative/fix

Instead of returning one vector of parameters, the LARS solution returns the 2D array coef_path_ of shape (n_features, max_features + 1). The values within the 2D array are the parameters of the model at each critical point on the path drawn by the l1 norm as the alpha parameter is decreased. The first column is always zero.

Might not be the clearest either tbh, you guys can probably come up with something much nicer.

COMMENT:
Thank you for opening this issue, @AhmetVCetin04.

In my opinion, there is certainly room to improve the user guide, but the suggested alternative doesn't quite make the explanation clearer, and applying it directly would not qualify as a proper fix.

That said, it's a helpful starting point for thinking about ways to improve the corresponding section of the user guide, as technical documentation often involves some subjectivity.

Just my $0.02.

Labels: Documentation
1.1.8 LARS Lasso at Mathematical Formulation

### Describe the issue linked to the documentation

Instead of giving a vector result, the LARS solution consists of a curve denoting the solution for each value of the l1 norm of the parameter vector.

* not a curve
* "curve" is not computed at every point
* infinitely many solutions of the l1 norm of the parameter vector

### Suggest a potential alternative/fix

Instead of returning one vector of parameters, the LARS solution returns the 2D array coef_path_ of shape (n_features, max_features + 1). The values within the 2D array are the parameters of the model at each critical point on the path drawn by the l1 norm as the alpha parameter is decreased. The first column is always zero.

Might not be the clearest either tbh, you guys can probably come up with something much nicer.

COMMENT:
i would like to work on this documentation

Labels: Documentation
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
ping @thomasjpfan @ogrisel

Labels: Enhancement, help wanted