I know that in PyParis, we spoke with someone in GitHub where they mentioned that ahead of time, we could require some more credits for participants if needed. I would not be against having this solution as a plan B whatever else does not work.

I would be happy to have this option, and I would even use it as a plan A for people who come to a spring w/o setting up their machine.

Thanks for the feed-back, I opened a draft PR with the needed .devcontainer folder #31096. I will look into adding some short doc next week.

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

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??

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.

I agree we can get started with a simple #31096.

Not something we need to do now or something that is worth if it adds a lot of complexity.

Optimizing the devcontainer startup time does add complexity. Github does have prebuilds, but I can not tell if we can share pre-builds on this repo with forks. If a user can go to the main scikit-learn/scikit-learn repo and click on "Open codespaces" and then push to their fork, then maybe they could use our GitHub prebuilds. We should test it out once #31096 gets merged.

If we can not use prebuilds we need to have a public custom base image for the dev container. Here is the optimization strategies: (with increasing complexity)

1. Build a custom base image with our dev dependences. We build the image weekly, because these do not change that frequently.
2. In our custom base image, install ccache and compile scikit-learn. This means forks can use this image and have a faster time building scikit-learn. I have tried this before with GitPod with SciPy, and it works.
3. In our custom base image, build the docs to cache the docs build. We likely need to mess with the mtime of files to get sphinx to recognize the cache when using the devcontainer in a fork. (I have not figure out the right way to do this 😅)