Live data from Hacker News

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

blog.pyodide.org

41–44 of 44 posts

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

#41
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/

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

#42

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…

crates.io is for distributing source code, pypi is primarily for distributing wheels which contain a mixture of Python code and compiled shared libraries.

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

#43
post #3

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_…

Here are all of the existing emscripten-forge recipes for building WASM packages: https://github.com/emscripten-forge/recipes/tree/main/recipe...

From https://news.ycombinator.com/item?id=43201706 :

> jupyterlite-xeus supports environment.yml with jupyterlite with packages from emscripten-forge: https://jupyterlite-xeus.readthedocs.io/en/latest/environmen...

emscripten-forge was a Quetz repo built with but is now hosted on prefix.dev.

From https://emscripten-forge.org/blog/ :

  pixi run setup

  pixi run build-emscripten-wasm32-pkg recipes/recipes_emscripten/regex
Pixi doesn't yet support building wheels though, just conda recipes.

Does cibuildwheel already have this new support for building WASM pyodide packages?

Does jupyterlite's `micropip install` install these new WASM packages from PyPI?

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

#44

Earlier quoted context omitted.

I don't think the controversy about Wasm's structured control flow has anything to do with any of this? It's not actually difficult to target Wasm in codegen; I've never heard of any real-world compiler project complaining that this was a major burden. ABI concerns are at a different level. Most low-level IRs don't do structured control flow because most low-level IRs don't need to be translatable to verified-safe ma…

http://troubles.md/posts/why-do-we-need-the-relooper-algorit... has a more detailed version of this argument: if WebAssembly had used a CFG as the basis for its control flow, it would have been easier to compile to and easier to efficiently execute/translate while maintaining safety, and maybe GCC would have released a WebAssembly backend by now. The author alleges that the real reason WebAssembly uses loop/block is…

I'm familiar with that post. However, it doesn't include a convincing argument that a CFG interchange format wouldn't have performance costs for Wasm runtimes; it just handwavingly asserts this. It blames Google because Google is a popular villain, but the other three browser vendors (this was before Edge adopted Chromium), all of which initially used different Wasm runtime architectures from Google and from one another, were also in favor of structured control flow, and I assume they knew what they were talking about. Once you get past the conspiracy theory, it's clear that the real issue is just that the author disagrees with the Wasm committee's decision to trade off convenience for compiler writers in order to make things work better for runtimes.

More to the point, none of this has anything to do with ABI.

Post reply on HN