Add Pyodide (WASM) wheel build and release asset

[ericmjl]

Summary

• Replaces the old "Build universal wheel for Pyodide" job (PYODIDE=1 + setup.py bdist_wheel --universal) with a proper pyodide-build + Emscripten job that produces a wasm32 wheel.
• Adds a job that uploads the Pyodide wheel to the GitHub Release as an asset when a release is published (PyPI does not yet accept wasm32 wheels).
• Adds optional dependency pyodide in pyproject.toml and documents the manual Pyodide build in the dev guide; no Pixi or other new tooling.
• Removes Pixi-only references: .pixi from pre-commit sphinx-lint args, and conda/mamba/pixi → conda/mamba in cmodule and troubleshooting docs.

Numba remains optional on wasm via existing environment markers, so the Pyodide wheel is micropip-installable without numba.

CI changes

• build_pyodide_wheel: Python 3.12, install pyodide-build, get Emscripten version, mymindstorm/setup-emsdk, pip install -e ".[pyodide]", pyodide build, upload pyodide_wheel artifact.
• upload_pyodide_to_release: On release published, download pyodide_wheel and attach to the release via softprops/action-gh-release.
• upload_pypi: No longer downloads or uploads the old universal_wheel; PyPI receives only sdist + cibuildwheel platform wheels.

Made with Cursor

[ricardoV94]

@ericmjl for future reference we prefer devs to contribute from their forks instead of working on the main repo directly

[ericmjl]

@ericmjl for future reference we prefer devs to contribute from their forks instead of working on the main repo directly

I'm pretty sure I'm working from my own fork 😄

[lucianopaz]

Wouldn't it be good to add a line some in the README.md or the docs landing page saying how to install on a wasm environment? Wouldn't users have to put in the full url of the github release to install?

[ricardoV94]

@ericmjl for future reference we prefer devs to contribute from their forks instead of working on the main repo directly

I'm pretty sure I'm working from my own fork 😄

You sure are, I wasn't seeing the ericmjl prefix before on my desktop. On the mobile I see

[ericmjl]

@lucianopaz addressed your comment too.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[maresb]

@ericmjl, heads-up in case you didn't notice, there are lots of merge conflicts from your last force-push.

[ricardoV94]

just the branch target

[anutosh491]

Hi,

This is Anutosh here (Jupyterlite, LLVM, Clang, Clang-Repl & Emscripten-Forge maintainer/contributor)

I have successfully built numba & llvmlite for wasm. I spoke about upstreaming my patches in the Numba community call yesterday and we should be making progress there. For more technical details go through my comment here : numba/numba#3284 (comment)

You can try out Numba in Jupyterlite here : https://notebook.link/@anutosh491/numba

I had interacted with Thomas Wiecki (@twiecki) about 2 weeks back on my LinkedIn post talking about how PyTensor could benefit out of this.

Hence I went ahead and built PyTensor for wasm enabling Numba as PyTensor's WebAssembly linker.

Check it out here, I have hosted a simple demo notebook to start with : https://notebook.link/@anutosh491/PyTensor (enable the debug logs to see how numba functions in the backend)

cc @ricardoV94 @maresb @lucianopaz

Feel free to contact us (me, @SylvainCorlay or @MMesch) at QuantStack for more details. We are the main authors of Jupyterlite and would like to host a Jupyterlite notebook in PyTensor's readme. We should possibly be able to shift tutorials or examples that users want to try out in Jupyterlite itself.

[ericmjl]

Alrighty, @ricardoV94 and @maresb -- looks like we're in a good spot now.

[ericmjl]

Hey @anutosh491 — first off, thank you so much for this, it's genuinely exciting! Building numba + llvmlite for wasm and wiring it up as PyTensor's WebAssembly linker is a huge piece of work, and the JupyterLite demo is such a lovely touch. Really appreciate you (and the QuantStack crew) pushing this forward.

I spent some time today tracing through our build to make sure I actually understand what's needed on our side, and I'd love to sanity-check my mental model with you:

• PyTensor is, for all functional purposes, pure-Python. The only compiled piece is one Cython module (scan_perform, a scan speed-up); it's never imported at package load and has a complete pure-Python fallback. The runtime C codegen is only used by the C linker backend, which Pyodide doesn't touch.
• So the pure-Python wheel we already ship to PyPI (pytensor-…-py3-none-any.whl) is installable via micropip.install("pytensor") in Pyodide today, and works.

If I'm reading this right: on the PyTensor side we don't need a compiled wasm build at all — the pure-Python wheel on PyPI is the deliverable. The remaining piece for the fully-automagical micropip.install("pymc") → numba-in-the-browser experience is numba/llvmlite publishing pyemscripten_*_wasm32 wheels to PyPI (your emscripten-forge builds today; upstream once the numba patches land). Once those exist, PyTensor pulls numba in automatically — no marker, no special build, nothing.

Is that understanding correct? And if so, my plan is to unwind the pyodide build / Emscripten machinery in this PR (it's not producing a usable artifact today anyway) and reduce it to: keep the pure-Python wheel flowing to PyPI + update the install docs to point folks at micropip.install("pytensor") (with numba via emscripten-forge / JupyterLite in the meantime). Sound right to you, @ricardoV94 / @maresb / @lucianopaz?

Either way — thank you again. This is really cool. 😄

[anutosh491]

Hey @ericmjl ,

Thanks for asking!

I think there are two slightly different deployment paths being discussed here.

PyTensor’s pure-Python wheel is portable, but the Numba and llvmlite support I demonstrated is currently delivered through xeus-python and emscripten-forge. Those packages target our JupyterLite Emscripten runtime; they are not yet PyEmscripten/PEP 783 wheels for Pyodide. Producing those wheels would be a separate compatibility effort because we would need to align and test the compiler, linker and dynamic-loading stack against the PyEmscripten ABI.

What we can support immediately is an official PyTensor JupyterLite deployment !!
I can open a PR that builds the current PyTensor source in CI, creates a wasm32 environment using xeus-python, Numba and llvmlite from emscripten-forge, runs a small Numba-backed PyTensor example, and deploys the result to GitHub Pages.

There are also a few small PyTensor fixes currently carried by the emscripten-forge recipe. I’ll start by upstreaming the most important one separately: replacing hard-coded 64-bit indices in the Numba vectorized code generator with target-sized intp values. Made that here : #2334

Once that is reviewed, I can rebase the JupyterLite CI PR on top of it. Made it here : #2336 (based on #2335)

Longer term, PEP 783 wheels could also open a Pyodide/micropip path, but we don’t need to wait for that to provide a working Numba-enabled browser experience today.

[anutosh491]

Also that being said I see pytensor has all these backends

1) NumbaLinker   → Python/NumPy-like function → numba.njit → LLVM → WASM
2) JAXLinker     → JAX function               → jax.jit
3) PytorchLinker → PyTorch function           → torch.compile
4) MLXLinker     → MLX function               → mx.compile

We've worked on supporting the first one now but I think we can do justice with the other backend being built for wasm too !!
We would be looking for funding to do the attempt and then plug them back in Pytensor while collaborating with the Pytensor team. Please let us know if that's something that excites y'all 😄 !

[ricardoV94]

If everything is wasm at the end of the day I don't think there's a point in supporting the others as a bridge to wasm as far as PyTensor is concerned. That's something those other packages may want, but for us it doesn't matter.

We don't even need that it be the numba backend that bridges to it, rather whatever is easier and most performant in the end. See for instance a more streamlined pure python (aka numpy) backend: #2193

[anutosh491]

Hmmm so I guess it's about supporting a backend (possibly the best performance wise) end to end rather than multiple ones.

[anutosh491]

Also @ricardoV94 could you help me with enabling ci for my other prs

[ricardoV94]

Also @ricardoV94 could you help me with enabling ci for my other prs

Now that the first one got merged it should fire automatically on new pushes/PRs. It's the first time contributor ruler that was blocking before

[ricardoV94]

Hmmm so I guess it's about supporting a backend (possibly the best performance wise) end to end rather than multiple ones.

Yes. And by performant is whatever generates better webasm code

[anutosh491]

Now that the first one got merged it should fire automatically on new pushes/PRs. It's the first time contributor ruler that was blocking before

Thank you. I've re-run the CI on my PRs.