Talip7/scikit-learn-issues-multilabel huggingface dataset:
RFC set up Codespaces to ease contributor experience especially during sprints?

IMO this could be useful as fall-back during sprints, in particular for pesky company Windows laptops, where I (and others for example @adrinjalali and @glemaitre) have been guilty to debug the Windows situation rather than focussing on more important stuff 😅.

Try it on my fork https://github.com/lesteve/scikit-learn

![Image](https://github.com/user-attachments/assets/d0673441-59f5-4abb-b41b-af267602eb64)

Full disclosure: for some reason, this does not work for me on Firefox, I need to use a Chromium-like browser (Vivaldi works for example), maybe due to my addons not sure.

![Image](https://github.com/user-attachments/assets/6ade7d69-626b-4a90-8a7c-67f22e5f65c9)

The setup seems quite maintable see current diff https://github.com/scikit-learn/scikit-learn/compare/main...lesteve:scikit-learn:main. This could be tweaked for example to setup `ccache` if we insist but I think is good enough as is.

I tried it on my fork on a 2-core machine (default):
- build time from scratch: ~7 minutes
- run full test suite: ~13 minutes (with or without `-n2` has similar timings)
- doc `make html-noplot` (i.e. no example) ~9 minutes first time, ~1 minute second time

Pricing: 120 core hours + 15GB storage free per month. With the default 2-core machine, which is probably enough for sprints. See [doc](https://docs.github.com/en/billing/managing-billing-for-your-products/managing-billing-for-github-codespaces/about-billing-for-github-codespaces#monthly-included-storage-and-core-hours-for-personal-accounts) for more details.

I guess we may want to add light documentation about it somewhere.

- numpy mentions codespaces without much detailed instructions:
  https://numpy.org/doc/2.1/dev/development_environment.html
- scipy does something similar:
  https://docs.scipy.org/doc/scipy/dev/dev_quickstart.html#other-workflows

Previous related conversations:
- devcontainer: https://github.com/scikit-learn/scikit-learn/pull/27743
- gitpod: https://github.com/scikit-learn/scikit-learn/pull/23556

COMMENT:
Thanks for the feed-back, I opened a draft PR with the needed `.devcontainer` folder https://github.com/scikit-learn/scikit-learn/pull/31096. I will look into adding some short doc next week.

Labels: RFC
RFC set up Codespaces to ease contributor experience especially during sprints?

IMO this could be useful as fall-back during sprints, in particular for pesky company Windows laptops, where I (and others for example @adrinjalali and @glemaitre) have been guilty to debug the Windows situation rather than focussing on more important stuff 😅.

Try it on my fork https://github.com/lesteve/scikit-learn

![Image](https://github.com/user-attachments/assets/d0673441-59f5-4abb-b41b-af267602eb64)

Full disclosure: for some reason, this does not work for me on Firefox, I need to use a Chromium-like browser (Vivaldi works for example), maybe due to my addons not sure.

![Image](https://github.com/user-attachments/assets/6ade7d69-626b-4a90-8a7c-67f22e5f65c9)

The setup seems quite maintable see current diff https://github.com/scikit-learn/scikit-learn/compare/main...lesteve:scikit-learn:main. This could be tweaked for example to setup `ccache` if we insist but I think is good enough as is.

I tried it on my fork on a 2-core machine (default):
- build time from scratch: ~7 minutes
- run full test suite: ~13 minutes (with or without `-n2` has similar timings)
- doc `make html-noplot` (i.e. no example) ~9 minutes first time, ~1 minute second time

Pricing: 120 core hours + 15GB storage free per month. With the default 2-core machine, which is probably enough for sprints. See [doc](https://docs.github.com/en/billing/managing-billing-for-your-products/managing-billing-for-github-codespaces/about-billing-for-github-codespaces#monthly-included-storage-and-core-hours-for-personal-accounts) for more details.

I guess we may want to add light documentation about it somewhere.

- numpy mentions codespaces without much detailed instructions:
  https://numpy.org/doc/2.1/dev/development_environment.html
- scipy does something similar:
  https://docs.scipy.org/doc/scipy/dev/dev_quickstart.html#other-workflows

Previous related conversations:
- devcontainer: https://github.com/scikit-learn/scikit-learn/pull/27743
- gitpod: https://github.com/scikit-learn/scikit-learn/pull/23556

COMMENT:
The timings you quote in the description look good enough to be a useful fallback. +1 for adding minimal documentation to your PR.

Labels: RFC
RFC set up Codespaces to ease contributor experience especially during sprints?

IMO this could be useful as fall-back during sprints, in particular for pesky company Windows laptops, where I (and others for example @adrinjalali and @glemaitre) have been guilty to debug the Windows situation rather than focussing on more important stuff 😅.

Try it on my fork https://github.com/lesteve/scikit-learn

![Image](https://github.com/user-attachments/assets/d0673441-59f5-4abb-b41b-af267602eb64)

Full disclosure: for some reason, this does not work for me on Firefox, I need to use a Chromium-like browser (Vivaldi works for example), maybe due to my addons not sure.

![Image](https://github.com/user-attachments/assets/6ade7d69-626b-4a90-8a7c-67f22e5f65c9)

The setup seems quite maintable see current diff https://github.com/scikit-learn/scikit-learn/compare/main...lesteve:scikit-learn:main. This could be tweaked for example to setup `ccache` if we insist but I think is good enough as is.

I tried it on my fork on a 2-core machine (default):
- build time from scratch: ~7 minutes
- run full test suite: ~13 minutes (with or without `-n2` has similar timings)
- doc `make html-noplot` (i.e. no example) ~9 minutes first time, ~1 minute second time

Pricing: 120 core hours + 15GB storage free per month. With the default 2-core machine, which is probably enough for sprints. See [doc](https://docs.github.com/en/billing/managing-billing-for-your-products/managing-billing-for-github-codespaces/about-billing-for-github-codespaces#monthly-included-storage-and-core-hours-for-personal-accounts) for more details.

I guess we may want to add light documentation about it somewhere.

- numpy mentions codespaces without much detailed instructions:
  https://numpy.org/doc/2.1/dev/development_environment.html
- scipy does something similar:
  https://docs.scipy.org/doc/scipy/dev/dev_quickstart.html#other-workflows

Previous related conversations:
- devcontainer: https://github.com/scikit-learn/scikit-learn/pull/27743
- gitpod: https://github.com/scikit-learn/scikit-learn/pull/23556

COMMENT:
I think this will be useful for getting users started without the negative experience of spending half the sprint setting things up.

One thing we could ponder is if we can reduce the "time to working container" in some way. Basically instead of downloading mamba and creating an environment when the devcontainer launches, can we do this ahead of time. Maybe with a custom docker image? Or maybe there are options within the GitHub codespaces experience to have "pre launched" containers? Not something we need to do now or something that is worth if it adds a lot of complexity. As a side note: I rarely update the environment I use locally to do scikit-learn development, so prebuilding it for the container seems like it would work.

Maybe we can attract someone who is a devcontainers geek who can help with this.

edit: codespaces also doesn't work for me in Firefox :( I think you can use devcontainers for local development as well, if you use VS Code (or maybe other editors as well?). Maybe that would also help windows users, assuming that getting docker to work is easy??

Labels: RFC
RFC set up Codespaces to ease contributor experience especially during sprints?

IMO this could be useful as fall-back during sprints, in particular for pesky company Windows laptops, where I (and others for example @adrinjalali and @glemaitre) have been guilty to debug the Windows situation rather than focussing on more important stuff 😅.

Try it on my fork https://github.com/lesteve/scikit-learn

![Image](https://github.com/user-attachments/assets/d0673441-59f5-4abb-b41b-af267602eb64)

Full disclosure: for some reason, this does not work for me on Firefox, I need to use a Chromium-like browser (Vivaldi works for example), maybe due to my addons not sure.

![Image](https://github.com/user-attachments/assets/6ade7d69-626b-4a90-8a7c-67f22e5f65c9)

The setup seems quite maintable see current diff https://github.com/scikit-learn/scikit-learn/compare/main...lesteve:scikit-learn:main. This could be tweaked for example to setup `ccache` if we insist but I think is good enough as is.

I tried it on my fork on a 2-core machine (default):
- build time from scratch: ~7 minutes
- run full test suite: ~13 minutes (with or without `-n2` has similar timings)
- doc `make html-noplot` (i.e. no example) ~9 minutes first time, ~1 minute second time

Pricing: 120 core hours + 15GB storage free per month. With the default 2-core machine, which is probably enough for sprints. See [doc](https://docs.github.com/en/billing/managing-billing-for-your-products/managing-billing-for-github-codespaces/about-billing-for-github-codespaces#monthly-included-storage-and-core-hours-for-personal-accounts) for more details.

I guess we may want to add light documentation about it somewhere.

- numpy mentions codespaces without much detailed instructions:
  https://numpy.org/doc/2.1/dev/development_environment.html
- scipy does something similar:
  https://docs.scipy.org/doc/scipy/dev/dev_quickstart.html#other-workflows

Previous related conversations:
- devcontainer: https://github.com/scikit-learn/scikit-learn/pull/27743
- gitpod: https://github.com/scikit-learn/scikit-learn/pull/23556

COMMENT:
I think it worked for me on Firefox (macOS). I tried on @lesteve's fork.

What is implemented in #31096 is good enough for a start, and then we can incrementally optimize the start-up time in follow-up PRs.

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
I'm personally happy with depending on narwhals for all dataframe work.

I'm also okay with a hard dependency since it's a very lightweight lib with no transient dependencies. But I wouldn't say no to a soft dependency implementation, I just think it's nicer for users if it's always installed with sklearn.

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
Is there a way to positionally select the rows with narwhals? (This is important for `_safe_indexing`)

Concretely, how do I get the `[1, 3, 5]` positional rows in a narwhals compliant dataframe? In pandas, it would be this:

```python
import pandas as pd

x = pd.DataFrame({"a": [4, 2, 3, 4, 5, 6], "b": [3, 5, 14, 2, 421, 12]})

x.loc[[1, 3, 5], :]
```

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
Thanks for the ping!

Whether as a hard-dependency, soft-dependency, or vendored, I'd love to see this 😍 

@thomasjpfan yup, numpy-style indexing is supported on `narwhals.DataFrame` objects (but not on `narwhals.LazyFrame`, where [row order is undefined](https://narwhals-dev.github.io/narwhals/basics/order_dependence/)):
```python
In [8]: df = nw.from_native(x, eager_only=True)

In [9]: df
Out[9]:
┌──────────────────┐
|Narwhals DataFrame|
|------------------|
|       a    b     |
|    0  4    3     |
|    1  2    5     |
|    2  3   14     |
|    3  4    2     |
|    4  5  421     |
|    5  6   12     |
└──────────────────┘

In [10]: df[[1,3,5]]
Out[10]:
┌──────────────────┐
|Narwhals DataFrame|
|------------------|
|        a   b     |
|     1  2   5     |
|     3  4   2     |
|     5  6  12     |
└──────────────────┘
```
See [DataFrame.__getitem__](https://narwhals-dev.github.io/narwhals/api-reference/dataframe/#narwhals.dataframe.DataFrame.__getitem__). PyShiny makes heavy use of it

You may also be interested in [what about the pandas index?](https://narwhals-dev.github.io/narwhals/pandas_like_concepts/pandas_index/)

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
So currently, there is no critical voice, but still time to raise one. Please do so.

Let's see how contributors would prefer to add narwhals:
- 🚀 add narwhals as dependency like joblib
- 🎉 vendor narwhals within scikit-learn like liblinear or array-api-compat #30340

Please cast a vote by selecting one of the 2 emoijis as reaction to this comment.
Disclaimer: While still kind of informal, this will shed light on how to proceed.

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
The way that I had understood this proposal was: optional dependency not needed for pandas support, but needed for other dataframe support. I'm not against that proposal :).

But I was thinking: there will be an element of surprise, of "discomfort", which is that when users pass in a polars dataframe, they will get an error and will need to install narwhals to fix this error.

So my question is: what does, for polars support, narwhals gain us? We already have a decent support of polars.

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
fairlearn has just started to work on introducing narwhals one month ago. Here's the issue if somebody wants to have a look: https://github.com/fairlearn/fairlearn/issues/1522 

This was preceded by a [discovery process](https://github.com/narwhals-dev/narwhals/issues/204) led by the narwhals people, who are very helpful and quick! And also very interested to spread narwhals as wide as possible. I am sure we could ask them for a similar exploration for scikit-learn before making a decision.

The large difference to scikit-learn is that fairlearn uses pandas extensively within the classes, whereas scikit-learn converts to numpy (or another array library) at the earliest moment.

I agree with the more concerned voices who want to explore the extend first and understand the gains:

There is a large interruption between input and output already (in terms of using types from dataframe libraries), so where would narwhals then be beneficial? For converting the outputs into the same type as the inputs, if the user uses `set_output()`? Is that gain large enough compared to individual pandas/polars/ etc. conversions?

narwhals also supports more than `pandas` and `polars`, for instance `pyarrow` which has some efficiency-advantages, but not directly within scikit-learn (since array libraries are used). Is there any harm to convert the output afterwards, if users want to use it? I cannot see any. Users know what they want and don't need to write complicated conditions fitting any case, when they use an estimators predictions or a transformer's output.

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
> what does, for polars support, narwhals gain us? We already have a decent support of polars.

The main benefit I see is to have one code path that supports both pandas and polars. And open the door to toggle on other dataframe libraries.

---

It would be great to use their dataframe-first expression API, but that brings us too far from our current way of doing things. Status quo is:

1. ndarray -> compute on ndarray
2. array-api array -> compute on array-api array
3. dataframe -> convert to ndarray -> compute on ndarray

If we add dataframe-first expression API for compute, it'll add a third code path, which I do not really like:

4. dataframe -> compute using dataframe expression API

(Although 4. means we can have lazy dataframe support)

---

That being said, I think there is a net win for vendoring narwhals to more easily support polars & pandas at the same time.

> what is your plan for the future? Would the switch to narwhals be done in a single PR? Is it going to be a lengthy per-function/estimator process like array API support (hopefully not 😅)?

For me, I would:

1. Vendor narwhals and use [v1 of the narwhals spec](https://narwhals-dev.github.io/narwhals/backcompat/). (or v2 when they release it)
2. I suspect most of the changes are in  https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/utils/_set_output.py and https://github.com/scikit-learn/scikit-learn/blob/812ff67e6725a8ca207a37f5ed4bfeafc5d1265d/sklearn/utils/_indexing.py#L180
3. There are a few places where we use the dataframe interchange, which most likely need to update to narwhals.

From a user point of view, narhwals code change would be invisible to them and they get the same feature set.

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
Thanks all for the discussion! Just wanted to comment on

> Vendor narwhals and use [v1 of the narwhals spec](https://narwhals-dev.github.io/narwhals/backcompat/). (or v2 when they release it)

I'd suggest _either_ using `stable.v1` or vendoring, doing both is probably unnecessary.

The idea behind `stable.v1` is: "code you write today will keep working in all future versions of Narwhals". It guards against deprecations and breaking changes. If you're vendoring, then there's no risk of deprecations / breaking changes anyway 😄

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
For people who couldn't attend yesterday's call (04/29/25):

Narwhals runs all the downstream libraries' tests. This ensures that the projects which have adopted it don't break. So, scikit-learn's tests would be run as well.

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
Just for a quick update - we're approaching `narwhals.stable.v2`, and for the past few months that's been our main priority and focus. Once that's out the door, I'll turn my focus to this issue

Labels: RFC
RFC adopt narwhals for dataframe support

At least as of [SLEP018](https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/slep018/proposal.html), scikit-learn supports dataframes passed as `X`. In #25896 is a further place of current discussions.

This issue is to discuss whether or not, or in which form, a future scikit-learn should depend on [narwhals](https://github.com/narwhals-dev/narwhals) for general dataframe support.

`+` wide df support
`+` less maintenance within scikit-learn
`-` external dependency

@scikit-learn/core-devs @MarcoGorelli

COMMENT:
A lot more people now use polars, and our code breaks here and there with it, and we need to do continuous patch work to fix those issues. Not adopting narwhals is adding quite a bit of technical debt to our library at this point which I'm not very happy about.

At this point, there have been enough libraries out there which have adopted narwhals that I don't think the conservative views are justified much anymore. Also, with `narwhals.stable.v2`, things have matured to a very good extent and I doubt if we'd have major issues with it.

@lorentzenchr has also started working on this, and we just need community support for the work to move forward.

A few of the issues are linked in this project: https://github.com/orgs/scikit-learn/projects/15/views/2

Labels: RFC