The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

[ogrisel]

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: doc/jupyter-lite.json because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

[ogrisel]

/cc @jeremiedbb @lesteve

[glemaitre]

I open pyodide/pyodide#3976 to update the version of scikit-learn (or at least it is what I am aiming to)

I assume that we can update the version of pyodide once there is a new release with this new scikit-learn version.

[betatim]

Is it possible to build our own pyodide "distribution" (not sure what to call it, I'm referring to "the stuff that the pyodide project creates when they make a release")? That way we could build those artefacts as part of the docs with the latest version of scikit-learn.

It would also mean you can test drive changes that are on main by visiting the unstable docs. But I think that is more of a bonus feature.

[lesteve]

This has been discussed before. I think the most reasonable way forward is described in #25887 (comment).

• build a scikit-learn development wheel and upload it somewhere where it can be used by Pyodide (i.e. need some kind of CORS proxy)
• add %pip install <full-url-behind-cors-proxy> to the JupyterLite notebooks (through the sphinx-gallery notebook_modification_function)
• it means that the dev scikit-learn version will be used, but this has always been like this for Binder and nobody ever complained (or noticed)

One problem with having the wheel as part of the doc is that you add a ~6MB wheel on each push to the doc repo.

[ogrisel]

Alternatively we could hide the jupyterlite links on /stable between the time of release X.Y.Z and the time scikit-learn X.Y.Z is shipped with pyodide and push a commit to the maintenance branch to update /stable as soon as pyodide is up to date.

[ogrisel]

One problem with having the wheel as part of the doc is that you add a ~6MB wheel on each push to the doc repo.

We could push the wheel artifact to a dedicated organization on anaconda.org instead of shipping it from scikit-learn.org / githhub.io, no?

[lesteve]

We could push the wheel artifact to a dedicated organization on anaconda.org instead of shipping it from scikit-learn.org / githhub.io, no?

Yes we could and that's my favourite option, I was mostly responding to Tim about:

That way we could build those artefacts as part of the docs with the latest version of scikit-learn.

[rth]

I think the most reasonable way forward is described in #25887 (comment).

Yeah, +1 for that. Hopefully, pypa/cibuildwheel#1456 will be done soon and it would be enough to just enable that platform in cibuildwheel. But since currently it's still not possible to upload such wheels to PyPI, +1 for a dedicated organization on anaconda.org. For instance, Numpy is already running CI to build wheels for this platform so they could also upload them there.

Last we checked anaconda.org is still missing the CORS headers necessary to load them on a web page, and there hasn't been progress on it, but I'll try to raise this question with Anaconda people at EuroPython later this month.

[celestinoxp]

@ogrisel @glemaitre @betatim @lesteve @rth
pyodide updated its version to 0.24 on 13-September-2023... what else is missing?

[glemaitre]

We need to open a PR to update the version.