PyPI now accepts WASM wheels for Pyodide

PyPI now accepts Pyodide-compatible WASM wheels, removing a major packaging bottleneck for browser-side Python.

Pyodide just got a lot easier to package for. On 13 June 2026, Simon Willison wrote that Python packages built for WebAssembly can now be published straight to PyPI and installed at runtime in Pyodide.

That sounds small until you remember the old workflow: the Pyodide maintainers had to build, host, and review more than 300 packages themselves. For a browser-based Python runtime, that was a huge bottleneck.

What changed in PyPI

The key update is support for a new wheel platform tag: pyemscripten_202*_wasm32. That tag lets maintainers publish WebAssembly builds to PyPI in the same way they already publish Linux, macOS, or Windows wheels.

Willison points to the PyPI pull request that added support, which landed on 21 April 2026. The practical result is simple: a package author can ship a WASM build, and Pyodide can install it at runtime without a special side channel.

This matters because Pyodide is not a toy project. It is a full Python runtime compiled to WebAssembly, and it is one of the cleanest ways to run Python in the browser without server round-trips. When packaging gets easier, the ecosystem gets larger.

• Old model: Pyodide maintainers built and hosted packages themselves.
• New model: package authors publish their own WASM wheels to PyPI.
• Effect: fewer manual reviews and less maintenance overhead for the core team.
• Result: more packages can become available to browser-based Python apps.

Willison’s luau-wasm test case

To prove the workflow, Willison packaged his own experiment, luau-wasm, and published it to PyPI. The package wraps Luau, Roblox’s small embeddable language derived from Lua and written in C++.

He used Claude Code and GPT-5.5 to help package the project and wire up GitHub Actions. The package shipped as a 276 KB wheel named luau_wasm-0.1a0-cp314-cp314-pyemscripten_2026_0_wasm32.whl.

“Moving forward, package maintainers can simply build and publish Pyodide wheels to PyPI, just as they do for native wheels on Linux, macOS, or Windows.”

That quote from Willison gets to the heart of the change. The packaging model is now familiar enough that maintainers do not need a separate distribution path just for browser Python.

The repo also includes build and deploy scripts using cibuildwheel, plus an HTML demo at simonw.github.io/luau-wasm that loads Pyodide, installs the package, and runs code in the browser.

What 28 packages tells us

Willison also checked PyPI’s public BigQuery dataset and found 28 packages already publishing with the new WASM platform tags. That list includes pydantic_core, onnx, typst, and several Rust-backed packages such as yaml-rs and toml-rs.

That number is still small, but it is enough to show the pattern is real. The early adopters are mostly packages that already have native code or cross-compiled components, which makes sense because those are the projects that benefit most from a browser-safe binary format.

• luau-wasm: a fresh example of a WASM wheel published to PyPI.
• pydantic_core: a widely used compiled dependency.
• onnx: a heavy-duty machine learning runtime component.
• typst: a toolchain project that benefits from compiled code.

For developers building browser-native Python apps, the implication is practical rather than theoretical. You can now imagine a future where a Pyodide app installs dependencies from the same index the rest of Python already uses, with less friction and fewer special cases.

Why this matters for browser Python

Pyodide has always had a strong pitch: real Python in the browser, backed by WebAssembly. The weak point was packaging. If a project needed a compiled extension, distribution often turned into a custom build problem instead of a normal release process.

This update removes a lot of that friction. It also makes it easier for maintainers to ship experimental browser builds without asking the Pyodide team to carry the operational load.

There is still work to do. More packages need to adopt the tag, build tooling needs to keep improving, and maintainers need a clear path from source tree to wheel. But the important part is already here: the registry now knows how to accept the artifact.

For anyone building with Pyodide, the next useful question is simple: which dependencies can be published as WASM wheels this quarter, and which ones still need custom handling?

If adoption keeps climbing from 28 packages to a few hundred, browser-based Python will start to feel much less like a special project and much more like ordinary Python with a different target.