ENH: build the dev MNE wheel for JupyterLite (JupyterLite split 2/5) - #14135
ENH: build the dev MNE wheel for JupyterLite (JupyterLite split 2/5)#14135natinew77-creator wants to merge 22 commits into
Conversation
Adds a script that builds MNE as 9999.0.1 into doc/pypi, where the jupyterlite-pyodide-kernel piplite addon picks it up, and the CircleCI step that runs it once before Sphinx.
|
@teonbrooks PR 2 of the split is up. Thanks! |
|
I noticed that the scipy and matplotlib packages should be compatible with MNE https://pyodide.org/en/stable/usage/packages-in-pyodide.html do you know what version of Pyodide is being used? it may be that we need to bump the version of jupyterlite, which in terms bumps pyodide-kernel. it looks like the latest version of pyodide-kernel uses the 314 version of pyodide, which is built on 3.14 Python |
Pyodide 0.29.3 already ships scipy 1.14.1 and numpy 2.2.5, which satisfy MNE. Only matplotlib 3.8.4 falls short, so relax that bound and leave the rest.
Thanks for flagging. We're on Pyodide 0.29.3 (Python 3.13.2), from I did try the bump. It builds and loads Pyodide 314.0.1, where |
|
Tried the bump on #13925. Full build green with all pages executed |
Overrides jupyterlite-sphinx's jupyterlite-core cap so the docs build picks up pyodide-kernel 0.8.2. Its matplotlib, scipy and numpy all clear MNE's minimums, so the wheel build no longer patches pyproject.toml at all.
Same content as the PR 2 branch so the two do not conflict when it merges. Drops the pyproject patching, which Pyodide 314 makes unnecessary.
natinew77-creator
changed the title
natinew77-creator
changed the title
jupyterlite-sphinx 0.23.0 raised its jupyterlite-core cap to < 0.9, so the resolution reaches Pyodide 314 without help now. The overrides stay as a floor against falling back to the old kernel, which the comment now says instead.
The 1.17.1 figure came from an early 314.0.1 probe. The 314.0.4 lockfile, which is what the pinned kernel resolves to, has scipy 1.18.0. Still above MNE's 1.14 floor, so nothing else changes.
teonbrooks
left a comment
teonbrooks
left a comment
There was a problem hiding this comment.
added some comment. overall it looks good
Switches to pathlib, which drops the glob import entirely rather than just narrowing it. The clean step stays, but the comment now says what it actually does: the version is pinned, so the filename is constant and wheels never piled up. The point is that the piplite index holds this build's wheel and nothing else. The failure now names the PyPI release the browser would otherwise fall back to.
2 participants
Part 2 of the split of #13925. Part 1 is #14128.
Adds
doc/sphinxext/build_lite_wheel.py, which builds MNE as 9999.0.1 intodoc/pypi. The piplite addon picks wheels up from there, so the browser kernel installs the development version rather than the older PyPI release. A CircleCI step runs it once before Sphinx.Also moves the browser to Pyodide 314. jupyterlite-sphinx used to cap jupyterlite-core below 0.8, which held the kernel on Pyodide 0.29.3 and its matplotlib 3.8.4, just under the 3.9 MNE declares. 0.23.0 has since raised that cap to
< 0.9, so the resolution reaches 314 on its own andtools/circleci_uv_overrides.txtnow just holds the floor against slipping back to the old kernel. Pyodide 314 ships matplotlib 3.10.8, scipy 1.18.0 and numpy 2.4.3, all of which satisfy MNE, so the wheel is built frompyproject.tomlas it stands with no version patching at all.Nothing installs the wheel yet. The Sphinx wiring follows in the next PR along with the list of pages that get an "Open in JupyterLite" badge, so badges do not land on pages that cannot run in the browser.
Checked on #13925 before landing it here: a full build is green with every page executed and no sphinx warnings, and the browser specific paths and the pandas 3.0 ones were run by hand.