Migrated from tech-debt.md (deleted, see repo history via git log -- tech-debt.md).
The live JupyterLite "Try it Now" deployment's docs/lite/pypi/all.json package index only listed a cp313 wasm wheel for roboticstoolbox-python, even though the pinned jupyterlite-pyodide-kernel==0.6.1 embeds Pyodide 0.27.6/CPython 3.12 and needs a cp312 wheel. Both wheel files were present at docs/lite/pypi/, but only cp313 made it into all.json -- piplite.install(["roboticstoolbox-python"]) failed with ValueError: Can't find a pure Python 3 wheel for 'roboticstoolbox-python'.
Root cause is upstream, in jupyterlite_pyodide_kernel/addons/piplite.py's get_wheel_index(): all_json[normalized_name]["releases"][version] = [release] assigns a fresh single-item list per (name, version) key instead of appending -- so when a release carries wasm wheels for more than one CPython version (as ours do, cp312 and cp313 both tagged the same version), whichever sorts alphabetically last silently overwrites the others. No build error, just a runtime failure in the browser. Confirmed not fixed in jupyterlite_pyodide_kernel 0.7.1 either (latest as of the last check) -- bumping the pin doesn't resolve it.
Fix applied (stopgap): narrowed the gh release download --pattern in ci.yml's "Fetch pyodide wheel for JupyterLite" step from *pyodide* to *cp312*pyodide*, so only the one wheel the pinned kernel actually needs ever reaches docs/lite/pypi/, sidestepping the upstream bug entirely.
Proposed real fix: the whole fetch-a-prebuilt-wasm-wheel-from-a-GitHub-release mechanism (and the CPython-tag pinning it depends on) is a maintenance burden in its own right. The real fix is a genuine py3-none-any pure-Python wheel published to real PyPI (no compiled _fknm_c/_frne_c) -- Pyodide's micropip resolves that automatically via its own standard fallback logic, no custom JupyterLite piplite index or GitHub-release-asset fetching required at all. Once that lands (tracked as a follow-on to the fknm/frne nanobind refactor work), this stopgap and the "Fetch pyodide wheel"/"Build JupyterLite site" CI steps should be revisited -- possibly removable outright.
Migrated from
tech-debt.md(deleted, see repo history viagit log -- tech-debt.md).The live JupyterLite "Try it Now" deployment's
docs/lite/pypi/all.jsonpackage index only listed acp313wasm wheel forroboticstoolbox-python, even though the pinnedjupyterlite-pyodide-kernel==0.6.1embeds Pyodide 0.27.6/CPython 3.12 and needs acp312wheel. Both wheel files were present atdocs/lite/pypi/, but onlycp313made it intoall.json--piplite.install(["roboticstoolbox-python"])failed withValueError: Can't find a pure Python 3 wheel for 'roboticstoolbox-python'.Root cause is upstream, in
jupyterlite_pyodide_kernel/addons/piplite.py'sget_wheel_index():all_json[normalized_name]["releases"][version] = [release]assigns a fresh single-item list per(name, version)key instead of appending -- so when a release carries wasm wheels for more than one CPython version (as ours do,cp312andcp313both tagged the same version), whichever sorts alphabetically last silently overwrites the others. No build error, just a runtime failure in the browser. Confirmed not fixed injupyterlite_pyodide_kernel0.7.1 either (latest as of the last check) -- bumping the pin doesn't resolve it.Fix applied (stopgap): narrowed the
gh release download --patterninci.yml's "Fetch pyodide wheel for JupyterLite" step from*pyodide*to*cp312*pyodide*, so only the one wheel the pinned kernel actually needs ever reachesdocs/lite/pypi/, sidestepping the upstream bug entirely.Proposed real fix: the whole fetch-a-prebuilt-wasm-wheel-from-a-GitHub-release mechanism (and the CPython-tag pinning it depends on) is a maintenance burden in its own right. The real fix is a genuine
py3-none-anypure-Python wheel published to real PyPI (no compiled_fknm_c/_frne_c) -- Pyodide's micropip resolves that automatically via its own standard fallback logic, no custom JupyterLite piplite index or GitHub-release-asset fetching required at all. Once that lands (tracked as a follow-on to the fknm/frne nanobind refactor work), this stopgap and the "Fetch pyodide wheel"/"Build JupyterLite site" CI steps should be revisited -- possibly removable outright.