Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI (blog.pyodide.org)

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

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

Here's how to try the new feature out. Visit https://pyodide.org/en/stable/console.html and type:

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

That gets you this WASM wheel: https://pypi.org/project/pydantic_core/#pydantic_core-2.47.0...

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

  pydantic_core._pydantic_core

I get this:

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

  pixi run setup

  pixi run build-emscripten-wasm32-pkg recipes/recipes_emscripten/regex

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

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.)

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

nice to see JS/python interop becoming a thing

[flagged]

[flagged]

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

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

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.

> 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!

[flagged]

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/