Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

I've been looking forward to this for ages!

This means we can now take any C/Rust/whatever extension for Python, compile that as a `.wasm` extension, and then load it directly in browser Pyodide projects using:

  await micropip.install("package-on-pypi")
  import package_name

  import micropip
  await micropip.install("pydantic_core")
  import pydantic_core

You can tell that it's got compiled code in (and not just Python) by running:

  pydantic_core._pydantic_core

  <module 'pydantic_core._pydantic_core' from '/lib/python3.14/site-packages/pydantic_core/_pydantic_core.cpython-314-wasm32-emscripten.so'>

Pyodide is great. I teach coding to kids, mostly creating 2d games with Python, and it was always a pain to manage an environment for each student. Now I have a browser based environment that runs Pygame/Arcade/Pyglet in Pyodide, so the kids can just do everything in the browser, I don't have to worry about Python versions, OS differences, files, etc. As a bonus they can easily publish what they make since it all runs in browser.

They haven't made anything too crazy, but performance is surprisingly good, even wiring in Pymunk for some physics stuff. If they get to the point where it's ever an issue they probably know enough to be working in a real game engine anyway.

Executing normal python programs inside a cpython vm inside a wasm context inside a javascript process inside a sandbox inside a browser is - genuinely - extremely exciting! (Might as well run the browser inside a container inside a VM while you're at it though.)

I've been working on a server-side wasm impl of cpython called boomslang [1] and have been thinking a lot lately about packaging, one of the downsides of my current impl is the need to statically link all c/rust extensions. Its too bad IMO how much of the wasm ecosystem targets/depends on emscripten directly. It'd be interesting to see if a more generic ABI could be provided for non emscripten/js based wasm runtimes.

[1] https://github.com/HubSpot/boomslang

This and PEP-783 do remind me a bit of the story of watt (1) and serde_derive, where the latter was published containing a to WebAssembly compiled proc macro with the former as WebAssembly runtime (2).

It tried amonst others to improve isolation and long compile times in a fairly foundational Rust library which can be found in many dependency trees. I found it a cool proof of concept at the time.

Having a WebAssembly binary embedded in a library was relatively unpopular in the Rust community (3). serde_derive 1.0.184 restored the uncompiled source version, but the release notes mention they hope that crates.io (Rust equivalent of PyPi) will add WebAssembly support in the future.

One of the reasons why this wasn't very popular was that WebAssembly is much harder to inspect than Rust source code (4).

I'm not a PyPi expert. The PEP itself seems to permit adding WebAssembly to a wheel (a python package). The PEP literally mentions "There are no security implications in this PEP" (security for whom?). In 2022 the supply chain attack surface was notably smaller since powerful enough LLM's didn't exist yet, yet it was for many a concern to include WebAssembly to package s in another ecosystem back then.

I do think other forms of binaries were already permitted, such as precompiled C/C++ libraries, so if that's true, then this is indeed relatively not that big of a security concern, but _no_ security implications seems to be a bit much.

I do see the added advantage to reduce friction of loading pre-compiled webassembly from PyPi directly instead of going through alternative packaging registries though.

(1) https://crates.io/crates/watt

(2) https://github.com/serde-rs/serde/commit/1afae183b06ffe47d05...

(3) https://github.com/serde-rs/serde/issues/2538

(4) https://old.reddit.com/r/rust/comments/15wx2xe/precompiled_b...

(5) https://peps.python.org/pep-0783/

Python in the browser keeps sounding ridiculous right up until it works.

I presume this works (will work) also for JupyterLite that is based on Pyodide ? Would be great if it helped getting the latest OpenCV-python version [0] and it's dnn goodies being available on a zero-install client side Notebook !

[0] https://news.ycombinator.com/item?id=48421858

Pyodide 314.0 is already available in xlwings Lite (the Python in Excel alternative you actually wanted).

Fantastic to have PyO3/Maturin guides too - the rust/python/typescript turducken I’ve always wanted.

Great news. And indeed a nice step to an even broader Python ecosystem.

> You might be wondering: wasn’t the last version 0.29, and now it’s 314.0?

Now Python's versioning scheme is officially worse than PHP's or Perl's. Not just skipping one version here - they are skipping 314 versions!

nice to see JS/python interop becoming a thing

[flagged]

[flagged]