Python.wasm roadmap

[assambar]

This is a loose list of next steps that we think would improve the python.wasm binary that we build.

Any feedback in comments is greatly appreciated.

• Build libz and libuuid in-house
• Port wasmedge socket support for listening and connecting
• Port to wasi-libc-19
• Research how to provide easy way/tooling to extend with modules that have a .so binary companion
  
• Port one of numpy, scikit, etc. as a result of the above
• Find a way to properly package it all in the same wasm binary
• Add documentation/examples of how to do bi-directional function calls between the Wasm guest and the host.
• Package an all-in-one libpython3.11.a archive for static linking into Wasm programs

[brettcannon]

Three questions and a request.

Question one: do you know about https://discuss.python.org/c/webassembly/28 ? It's where some announcements and discussions happen around Python and WebAssembly.

Question two: do you know about #Python channel on the WebAssembly Discord? It's the other place some of us participate around Python and WebAssembly.

Question three: Is anyone from VMWare looking to come to PyCon US this year? There may be a WebAssembly summit on Thursday, April 20 for a select number of people (space will be limited).

The request: please feel free to make suggestions upstream to improve how WASI is built, packaged, etc.! I want to get WASI to tier 2 support for CPython, and part of that will be creating WASI builds as part of releases. Trying to make sure those work as best as possible for the community would be great, so help would be appreciated. Discussions around that can happen at discuss.python.org or on a GitHub issue at https://github.com/python/cpython .

[cohix]

@assambar this is all excellent. I would love to see documentation/examples of how to do bi-directional function calls between the Wasm guest and the host. Specifically, calling a python function from the outside, and allowing python to call imported host functions other than those provided by WASI.

[assambar]

@brettcannon

Questions 1 and 2 - Did not know about both discussion channels. Subscribed to both. Many thanks!
Question 3 - I don't know of anyone going , but I will ask around the Wasm enthusiasts here and let them them know if there's anyone going.

The request: please feel free to make suggestions upstream to improve how WASI is built, packaged, etc.! I want to get WASI to tier 2 support for CPython, and part of that will be creating WASI builds as part of releases. Trying to make sure those work as best as possible for the community would be great, so help would be appreciated. Discussions around that can happen at discuss.python.org or on a GitHub issue at https://github.com/python/cpython .

Would love to. Suggestions will definitely come up as we see how people use python.wasm and what more they need. One thing is, we are currently working to also streamline building and publishing of reproducible, versioned WASI builds of popular libraries like libuuid, libz, libsqlite, etc. We will add more as need comes. Our idea is to have those as release assets so that it will be easier to build CPython with more modules out of the box. I will let you know when we have something, if you're interested.

[assambar]

@assambar this is all excellent. I would love to see documentation/examples of how to do bi-directional function calls between the Wasm guest and the host. Specifically, calling a python function from the outside, and allowing python to call imported host functions other than those provided by WASI.

Thanks for the feedback @cohix . Added this to the list of things to do in the beginning of this thread. Note that it's not a prioritized list.

[brettcannon]

I will let you know when we have something, if you're interested.

Yes please! My hope is we can get a "fat" binary build for WASI distributed on python.org with as much statically linked as possible so people can take that python.wasm file and run it anywhere they want.

[gzurl]

@brettcannon that feedback is very useful. Indeed, we just released two different flavors for PHP 8.2.0. A standard build with common extensions and a slimmed-down version with minimal size. I think we could follow a similar approach with Python.

Also, I believe a specific build focused on ML including the popular packages (NumPy, Pandas, Scikit, etc.) makes a lot of sense for running inference in the edge.

PS: We are waitlisted for a "charla" in PyCon

[codefromthecrypt]

Is it possible to move some of the blog content into a README alongside the python directories here? While I play devil's advocate sometimes, I'm really interested in what you are doing.

For example, I think you fairly mention in the blog that currently pip isn't usable, which reduces the size of docker images accordingly. Some people are looking at image size alone and missing out that firstly that's not the main goal and also it isn't fair to compare like this. Your blog is far more balanced, yet the points aren't visible in this repo.

https://wasmlabs.dev/articles/python-wasm32-wasi/

So, how about putting some things here? especially the part about pip I think is really important for a README, but I bet folks in the python community have their favorite things to say also.

[bivald]

Numpy would be awesome to have in this :) Let me know if I can test out anything when you get closer

[assambar]

I will let you know when we have something, if you're interested.

Yes please! My hope is we can get a "fat" binary build for WASI distributed on python.org with as much statically linked as possible so people can take that python.wasm file and run it anywhere they want.

Hey @brettcannon we published a "fat" binary with the latest release, relying on wasi-vfs, which turned out to be pretty easy. Take a look at python-3.11.1.wasm and python-3.11.1-wasmedge.wasm in python/3.11.1+20230217-15dfbed

Basically, you need to:

• link libwasi_vfs.a into the final wasm binary -
• run wasi-vfs CLI to pack it with the folders you want

Take a look at scripts/build-helpers/wasi_vfs.sh
and how the two functions from there are used in python/v3.11.1/wl-build.sh

[brettcannon]

relying on wasi-vfs

Are you referring to https://github.com/kateinoigakukun/wasi-vfs ? Or are you referring to something else?

• run wasi-vfs CLI to pack it with the folders you want

So you're trying to use wasi-vfs to ship files with the WASI binary so it's as self-contained as possible (short of the runtime)? I assume this only works with pure Python files and there isn't some magical dlopen() support in there? And the big bonus compared to freezing the code in with the binary is avoiding the compile step and instead relying on the wasi-vfs CLI to do the joining?

[assambar]

Are you referring to https://github.com/kateinoigakukun/wasi-vfs ?

Yep. That one.

So you're trying to use wasi-vfs to ship files with the WASI binary so it's as self-contained as possible (short of the runtime)?

Yep. We just packaged the usr/local/libs folder at / and we got an "all-in-one" python.wasm

I assume this only works with pure Python files and there isn't some magical dlopen() support in there?

Exactly. I'm still looking into how we could do this with modules that have C extensions. Without doing the uncharted dlopen support I'm currently thinking of compiling the extension files those to static wasm libs and then linking them along with libpython into a monolithic python.wasm, then packaging that with wasi-vfs. Naturally, a dlopen approach will be the best option, but I'm not sure how much time it will take to get it right. And it will require a host function.

And the big bonus compared to freezing the code in with the binary is avoiding the compile step and instead relying on the wasi-vfs CLI to do the joining?

I'd rather say the ease of use. It seems people get confused when they have to pre-open the standard library in order to use it.

[brettcannon]

I'm still looking into how we could do this with modules that have C extensions. Without doing the uncharted dlopen support I'm currently thinking of compiling the extension files those to static wasm libs and then linking them along with libpython into a monolithic python.wasm

This sounds similar to something we are starting to explore a little for VS Code: create an embedded interpreter scenario where we use https://docs.python.org/3/c-api/import.html#c.PyImport_AppendInittab to make extension modules act as built-in modules.

I'd rather say the ease of use. It seems people get confused when they have to pre-open the standard library in order to use it.

For some future WASI release on python.org, I've been thinking of freezing the stdlib into the binary and then letting people mount the stdlib if they want it for tracebacks. That way the simple, easy-to-deploy solution is available there, while you and the rest of the community innovate on nicer, fancier WASI solutions.

[assambar]

... create an embedded interpreter scenario where we use https://docs.python.org/3/c-api/import.html#c.PyImport_AppendInittab to make extension modules act as built-in modules.

That's exactly what I plan on doing.

For some future WASI release on python.org, I've been thinking of freezing the stdlib into the binary and then letting people mount the stdlib if they want it for tracebacks.

That would be awesome to have.

[brettcannon]

That's exactly what I plan on doing.

If you get to do the work in the open, do let us know and we can potentially coordinate or at least share notes (we are still just playing around, so no code to share, but it's being done in the open so we can talk about it, etc.).

[zifeo]

Great job for the fat binary, works like a charm!

Add documentation/examples of how to do bi-directional function calls between the Wasm guest and the host.

Is there already some pointers or tests I could use for that? I am especially interested to see how the host (e.g. WasmEdge via Rust) can run the Python guest continuously and trigger specific Python function on "event". Is there already something in that end (instead of relaunch the _start with different arguments)?