Talip7/scikit-learn-issues-multilabel huggingface dataset:
Trigger lockfile update with a comment

I've never been able to run the script to update the lock files w/o errors. My last attempt resulted in https://github.com/scikit-learn/scikit-learn/pull/28258#issuecomment-1910627538 which also didn't work, and that's after I had to install conda on my env, which I don't usually have since I use micro mamba.

It would be nice to be able to trigger a bot to update lock files the same way you can re-render on conda-forge. A comment with value similar to `@scikit-learn-bot please re-render` could update the lock files on the PR.

WDYT @lesteve ?

COMMENT:
I do have a small demo https://github.com/Charlie-XIAO/github-actions-test/pull/5 which only appends the command to execute to a file instead of actually executing the command, not sure if it suffices.

> Out of curiosity could you open a separate issue with the kind of errors you get when trying to update the lock-files on Windows. Some of it may be improvable you know 😉. Off the top of my head, it could be linked to limitations of conda-lock on Windows, something that the update script does not deal with on Windows, or plenty of other reasons.

I actually have different problems on my different machines as well. One of them that is that `subprocess.Popen` cannot recognize `conda` without setting `shell=True` but I don't think this should be fixed - it's more like a mis-setup of my environment since the same problem does not happen on my other machines. Another problem is the encoding error when there are failures in command probably because of the emojis in the command outputs. I have met some other errors a bit longer ago but cannot remember clearly. So overall I think these are more of my problem instead of the script's so might not be worth fixing (and just that I prefer spending some time to do this issue rather than fixing my messy environment(s) 😭).

Labels: Build / CI
Trigger lockfile update with a comment

I've never been able to run the script to update the lock files w/o errors. My last attempt resulted in https://github.com/scikit-learn/scikit-learn/pull/28258#issuecomment-1910627538 which also didn't work, and that's after I had to install conda on my env, which I don't usually have since I use micro mamba.

It would be nice to be able to trigger a bot to update lock files the same way you can re-render on conda-forge. A comment with value similar to `@scikit-learn-bot please re-render` could update the lock files on the PR.

WDYT @lesteve ?

COMMENT:
I had a quick look and indeed there are issues when trying to run the lock-files update script on Windows. 

Some are easily fixable: replace `conda` by `conda.bat` in the execute_command, that allows you to at least update the conda lock-files.

The part about pip-compile I still haven't figured it out. It seems like something like using `shell=True` and passing the right env with a tweaked `PATH` ...

Labels: Build / CI
Trigger lockfile update with a comment

I've never been able to run the script to update the lock files w/o errors. My last attempt resulted in https://github.com/scikit-learn/scikit-learn/pull/28258#issuecomment-1910627538 which also didn't work, and that's after I had to install conda on my env, which I don't usually have since I use micro mamba.

It would be nice to be able to trigger a bot to update lock files the same way you can re-render on conda-forge. A comment with value similar to `@scikit-learn-bot please re-render` could update the lock files on the PR.

WDYT @lesteve ?

COMMENT:
This has been done in https://github.com/scikit-learn/scikit-learn/pull/29505

Labels: Build / CI
ColumnTransformer output unexpected prefixed feature names from FunctionTransformer() step

### Describe the bug

The following code demonstrates that when `FunctionTransformer` is present as a step in `ColumnTransformer`, the feature names output are all prefixed with the name from the last step '**C__**'.  For example, column '**x1**' is output as '**C__x1**' for 3 times. 
When 'FunctionTransferformer' is _not_ present as a step, the feature names are corrected prefixed by the name in each steps. For example, column '**x1**' is output as '**A__x1**' and '**C__x1**' respectively, as expected. 

### Steps/Code to Reproduce

```python
import pandas as pd
from sklearn.preprocessing import FunctionTransformer, StandardScaler
from sklearn.compose import ColumnTransformer
from sklearn import set_config
set_config(transform_output='pandas') 

df = pd.DataFrame({
        'x1' : [1, 2, 3],
        'x2' : [10, 20, 30],
        'x3' : [100, 200, 300]})

my_coltransformer = ColumnTransformer([
    ('A', 'passthrough', ['x1', 'x2', 'x3']),
    ('B', FunctionTransformer(lambda x: x**2), ['x1', 'x2', 'x3']),
    ('C', StandardScaler(), ['x1', 'x2', 'x3'])])
transformed_df = my_coltransformer.fit_transform(df)
print(transformed_df)

my_coltransformer = ColumnTransformer([
    ('A', 'passthrough', ['x1', 'x2', 'x3']),
    #('B', FunctionTransformer(lambda x: x**2), ['x1', 'x2', 'x3']),
    ('C', StandardScaler(), ['x1', 'x2', 'x3'])])
transformed_df = my_coltransformer.fit_transform(df)
print(transformed_df)
```

### Expected Results

```
   A__x1  A__x2  A__x3  B__x1  B__x2  B__x3     C__x1     C__x2     C__x3
0      1     10    100      1    100  10000 -1.224745 -1.224745 -1.224745
1      2     20    200      4    400  40000  0.000000  0.000000  0.000000
2      3     30    300      9    900  90000  1.224745  1.224745  1.224745
```

### Actual Results

```
   C__x1  C__x2  C__x3  C__x1  C__x2  C__x3     C__x1     C__x2     C__x3
0      1     10    100      1    100  10000 -1.224745 -1.224745 -1.224745
1      2     20    200      4    400  40000  0.000000  0.000000  0.000000
2      3     30    300      9    900  90000  1.224745  1.224745  1.224745
```

### Versions

```shell
1.4.0
I tested this in 1.3.0 and did not observe the unexpected results.
```

COMMENT:
I can reproduce the issue. I'll investigate the reason.

Labels: Bug
ColumnTransformer output unexpected prefixed feature names from FunctionTransformer() step

### Describe the bug

The following code demonstrates that when `FunctionTransformer` is present as a step in `ColumnTransformer`, the feature names output are all prefixed with the name from the last step '**C__**'.  For example, column '**x1**' is output as '**C__x1**' for 3 times. 
When 'FunctionTransferformer' is _not_ present as a step, the feature names are corrected prefixed by the name in each steps. For example, column '**x1**' is output as '**A__x1**' and '**C__x1**' respectively, as expected. 

### Steps/Code to Reproduce

```python
import pandas as pd
from sklearn.preprocessing import FunctionTransformer, StandardScaler
from sklearn.compose import ColumnTransformer
from sklearn import set_config
set_config(transform_output='pandas') 

df = pd.DataFrame({
        'x1' : [1, 2, 3],
        'x2' : [10, 20, 30],
        'x3' : [100, 200, 300]})

my_coltransformer = ColumnTransformer([
    ('A', 'passthrough', ['x1', 'x2', 'x3']),
    ('B', FunctionTransformer(lambda x: x**2), ['x1', 'x2', 'x3']),
    ('C', StandardScaler(), ['x1', 'x2', 'x3'])])
transformed_df = my_coltransformer.fit_transform(df)
print(transformed_df)

my_coltransformer = ColumnTransformer([
    ('A', 'passthrough', ['x1', 'x2', 'x3']),
    #('B', FunctionTransformer(lambda x: x**2), ['x1', 'x2', 'x3']),
    ('C', StandardScaler(), ['x1', 'x2', 'x3'])])
transformed_df = my_coltransformer.fit_transform(df)
print(transformed_df)
```

### Expected Results

```
   A__x1  A__x2  A__x3  B__x1  B__x2  B__x3     C__x1     C__x2     C__x3
0      1     10    100      1    100  10000 -1.224745 -1.224745 -1.224745
1      2     20    200      4    400  40000  0.000000  0.000000  0.000000
2      3     30    300      9    900  90000  1.224745  1.224745  1.224745
```

### Actual Results

```
   C__x1  C__x2  C__x3  C__x1  C__x2  C__x3     C__x1     C__x2     C__x3
0      1     10    100      1    100  10000 -1.224745 -1.224745 -1.224745
1      2     20    200      4    400  40000  0.000000  0.000000  0.000000
2      3     30    300      9    900  90000  1.224745  1.224745  1.224745
```

### Versions

```shell
1.4.0
I tested this in 1.3.0 and did not observe the unexpected results.
```

COMMENT:
As a temporary workaround, setting `feature_names_out="one-to-one"` provide the expected results.

Labels: Bug
ColumnTransformer output unexpected prefixed feature names from FunctionTransformer() step

### Describe the bug

The following code demonstrates that when `FunctionTransformer` is present as a step in `ColumnTransformer`, the feature names output are all prefixed with the name from the last step '**C__**'.  For example, column '**x1**' is output as '**C__x1**' for 3 times. 
When 'FunctionTransferformer' is _not_ present as a step, the feature names are corrected prefixed by the name in each steps. For example, column '**x1**' is output as '**A__x1**' and '**C__x1**' respectively, as expected. 

### Steps/Code to Reproduce

```python
import pandas as pd
from sklearn.preprocessing import FunctionTransformer, StandardScaler
from sklearn.compose import ColumnTransformer
from sklearn import set_config
set_config(transform_output='pandas') 

df = pd.DataFrame({
        'x1' : [1, 2, 3],
        'x2' : [10, 20, 30],
        'x3' : [100, 200, 300]})

my_coltransformer = ColumnTransformer([
    ('A', 'passthrough', ['x1', 'x2', 'x3']),
    ('B', FunctionTransformer(lambda x: x**2), ['x1', 'x2', 'x3']),
    ('C', StandardScaler(), ['x1', 'x2', 'x3'])])
transformed_df = my_coltransformer.fit_transform(df)
print(transformed_df)

my_coltransformer = ColumnTransformer([
    ('A', 'passthrough', ['x1', 'x2', 'x3']),
    #('B', FunctionTransformer(lambda x: x**2), ['x1', 'x2', 'x3']),
    ('C', StandardScaler(), ['x1', 'x2', 'x3'])])
transformed_df = my_coltransformer.fit_transform(df)
print(transformed_df)
```

### Expected Results

```
   A__x1  A__x2  A__x3  B__x1  B__x2  B__x3     C__x1     C__x2     C__x3
0      1     10    100      1    100  10000 -1.224745 -1.224745 -1.224745
1      2     20    200      4    400  40000  0.000000  0.000000  0.000000
2      3     30    300      9    900  90000  1.224745  1.224745  1.224745
```

### Actual Results

```
   C__x1  C__x2  C__x3  C__x1  C__x2  C__x3     C__x1     C__x2     C__x3
0      1     10    100      1    100  10000 -1.224745 -1.224745 -1.224745
1      2     20    200      4    400  40000  0.000000  0.000000  0.000000
2      3     30    300      9    900  90000  1.224745  1.224745  1.224745
```

### Versions

```shell
1.4.0
I tested this in 1.3.0 and did not observe the unexpected results.
```

COMMENT:
We indeed refactor and use a dictionary to rename the columns: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/utils/_set_output.py#L125

But we overlooked that one could reuse the same column and then `x1` get remapped to the latest transformer. We should therefore pass a list instead.

Labels: Bug
ColumnTransformer output unexpected prefixed feature names from FunctionTransformer() step

### Describe the bug

The following code demonstrates that when `FunctionTransformer` is present as a step in `ColumnTransformer`, the feature names output are all prefixed with the name from the last step '**C__**'.  For example, column '**x1**' is output as '**C__x1**' for 3 times. 
When 'FunctionTransferformer' is _not_ present as a step, the feature names are corrected prefixed by the name in each steps. For example, column '**x1**' is output as '**A__x1**' and '**C__x1**' respectively, as expected. 

### Steps/Code to Reproduce

```python
import pandas as pd
from sklearn.preprocessing import FunctionTransformer, StandardScaler
from sklearn.compose import ColumnTransformer
from sklearn import set_config
set_config(transform_output='pandas') 

df = pd.DataFrame({
        'x1' : [1, 2, 3],
        'x2' : [10, 20, 30],
        'x3' : [100, 200, 300]})

my_coltransformer = ColumnTransformer([
    ('A', 'passthrough', ['x1', 'x2', 'x3']),
    ('B', FunctionTransformer(lambda x: x**2), ['x1', 'x2', 'x3']),
    ('C', StandardScaler(), ['x1', 'x2', 'x3'])])
transformed_df = my_coltransformer.fit_transform(df)
print(transformed_df)

my_coltransformer = ColumnTransformer([
    ('A', 'passthrough', ['x1', 'x2', 'x3']),
    #('B', FunctionTransformer(lambda x: x**2), ['x1', 'x2', 'x3']),
    ('C', StandardScaler(), ['x1', 'x2', 'x3'])])
transformed_df = my_coltransformer.fit_transform(df)
print(transformed_df)
```

### Expected Results

```
   A__x1  A__x2  A__x3  B__x1  B__x2  B__x3     C__x1     C__x2     C__x3
0      1     10    100      1    100  10000 -1.224745 -1.224745 -1.224745
1      2     20    200      4    400  40000  0.000000  0.000000  0.000000
2      3     30    300      9    900  90000  1.224745  1.224745  1.224745
```

### Actual Results

```
   C__x1  C__x2  C__x3  C__x1  C__x2  C__x3     C__x1     C__x2     C__x3
0      1     10    100      1    100  10000 -1.224745 -1.224745 -1.224745
1      2     20    200      4    400  40000  0.000000  0.000000  0.000000
2      3     30    300      9    900  90000  1.224745  1.224745  1.224745
```

### Versions

```shell
1.4.0
I tested this in 1.3.0 and did not observe the unexpected results.
```

COMMENT:
I'll submit a patch.

/take

Labels: Bug
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
+1, since these are closed:

- https://github.com/scikit-learn/scikit-learn/issues/17102
- https://github.com/scikit-learn/scikit-learn/issues/27086

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
Since this is only a build dependency I would be inclined to bump.

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
+1 for using Cython>=3.0.8 as a build dependency.

Should we milestone it for 1.5?

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
If some of the PR above are bug fixes, then we would need to target for the bug fix release.

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
I'll submit a PR to bump the min version.

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
A bit confused. cython=3.0.8 doesn't seem to be on conda-forge: https://anaconda.org/conda-forge/cython/files

However, two weeks ago the 3.0.8 build PR was merged: https://github.com/conda-forge/cython-feedstock/pull/133

Opened this to ask: https://github.com/conda-forge/cython-feedstock/issues/134

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
Seems like the files have been uploaded quite recently:
https://anaconda.org/conda-forge/cython/files
I seem to remember there is some small delay (maybe 1-2 hours) between the upload and the fact they are visible by `conda install`

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
Ah right I am reading the issue you opened so there was indeed an issue which was fixed. Now files have been uploaded and there is this small delay to wait.

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
What do we do about anaconda main channel? (I have wanted to ditch that completely for a while).

cython=3.0.6 is the latest there.

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
> What do we do about anaconda main channel? 

Can we ignore them?

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
> Can we ignore them?

I would love to. But a few of us insist on keeping main channel on the CI 😁 in #28284 I'm installing cython from pypi on those CI runs.

Labels: Build / CI
RFC bump Cython minimum supported version to 3.0.8

Currently we still have Cython 0.29.33 as our minimum Cython version. We may want to decide to bump our Cython requirement to Cython >= 3.0.8. I am +1 for this given that:

- https://github.com/scikit-learn/scikit-learn/issues/27682 needs Cython >= 3
- https://github.com/scikit-learn/scikit-learn/pull/28233 needs Cython >= 3.0.8
- numpy and scipy require Cython >= 3 in their `main` branch: https://github.com/scikit-learn/scikit-learn/issues/27682#issuecomment-1865961137

COMMENT:
Thank you, @adrinjalali.

Labels: Build / CI
ridge regression, objective function

### Describe the workflow you want to enable

add another option to define the objective function in another way. currently, the objective function is defined as ||y - Xw||^2_2 + alpha * ||w||^2_2, but when the number of observations, n, is huge. The l2 penalty plays a tiny role, sometimes the objective function needs to be  ( ||y - Xw||^2_2)/n + alpha * ||w||^2_2. 

### Describe your proposed solution

I think the solution is straightforward, at least for some solvers.

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

_No response_

### Additional context

_No response_

COMMENT:
First, this is intended behavior. Second, you can just set another value of alpha yourself. Third, you should set alpha anyway, e.g. by cross validation, and you should not rely on the default value, only for large data where the intended behavior of a tiny penalty applies. Which brings us back to the first point.

Labels: New Feature, Needs Triage