ENH: build the dev MNE wheel for JupyterLite (JupyterLite split 2/5) - #14135
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.
teonbrooks
left a comment
teonbrooks
left a comment
There was a problem hiding this comment.
looks good. minor some minor suggestions. once those land, then it'll lgtm
|
Sorry to come late to this PR, but I think a simpler scheme would be:
I don't think we should need all the version checking etc. But I could be missing something here with this simpler design, thoughts? |
Not missing anything, you're right on both counts. SETUPTOOLS_SCM_PRETEND_VERSION is gone. I'd assumed a .dev version would lose to the stable release on PyPI, but piplite returns as soon as it finds the package in the local index and never consults PyPI. Built it unpinned to confirm: mne-1.13.0.dev299+g8926cd4f0, resolves fine. .circleci is untouched now, identical to main. circleci_download.sh only ever writes html-memory or html-pattern-memory, and both go through the new jupyterlite_wheel target. I kept it as Python rather than shell for one reason: Teon asked for the error to name the PyPI version the browser would fall back to, which needs the metadata lookup. It's behind a make target now and short-circuits on an existing wheel as you suggested. Happy to go further if you'd still prefer the script. |
larsoner
left a comment
larsoner
left a comment
There was a problem hiding this comment.
Okay LGTM, marking for merge-when-green. Thanks in advance @natinew77-creator !
|
thanks @natinew77-creator! |
You're welcome, and thank you for the review. |
3 participants
Part 2 of the split of #13925. Part 1 is #14128.
Adds
doc/sphinxext/build_lite_wheel.pyand ajupyterlite_wheeltarget that everymake html*depends on, so the wheel is built once before Sphinx with no CircleCI change. The piplite addon picks wheels up fromdoc/pypi, so the browser kernel installs the MNE the surrounding pages are built from rather than the last release on PyPI.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 raised that cap to
< 0.9, so the two floors now sit in thedocdependency group inpyproject.tomlandtools/circleci_uv_overrides.txtis untouched. 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.