componentize-py

The WASI support in CPython has moved along very well and it is an early target via componentize-py[1]. Notes on WASI support in Python can be found in PEP 816[2]; CPython will be jumping from 0.1 to 0.3 (0.2 is adapted in componentize-py) which should unlock a fair bit of support, especially once cooperative threads lands (providing a pthreads impl in wasi-libc). [1] https://github.com/bytecodealliance/componentize-py [2] https://peps.python.org/pep-0816/

I've been collecting a list of sandboxing related projects as well, some lower level than others. I wish I had time to evaluate them all: - https://github.com/jingkaihe/matchlock - https://github.com/mishushakov/libkrun-go - https://github.com/earendil-works/gondolin - https://github.com/butter-dot-dev/bvisor - https://github.com/amlalabs/amla-sandbox - https://github.com/eryx-org/eryx - https://github.com/containers/bubblewrap (not new) - https://github.com/coplane/localsandbox - https://github.com/sd2k/conch - https://github.com/Gerharddc/litterbox - https://github.com/finbarr/yolobox - https://github.com/coventry/sandbox-codex - https://github.com/osks/ctenv - https://github.com/tianon/gosu - https://github.com/colony-2/shai - https://github.com/rcarmo/agentbox - https://github.com/coder/httpjail - https://github.com/bytecodealliance/c

I had to do some research to figure out what this is actually doing. When you try to pass e.g. strings through WASM functions you end up writing the data to memory and passing offset / length, which is obviously inconvenient and potentially has security implications. WASM components [1] is a spec that tries to improve on this with an IDL called WIT that lets you define functions that pass complex types with a proper ABI. This all seems sensible for languages like C or Zig that neatly cross compile to WASM. But I was very confused how this could ever work with a duck-typed interpreted language like Python, so I did some digging. Apparently "run your Python as WASM" part is implemented by componentize-py which cross compiles CPython to WASM as libpython3.14.so [2]. I'm not sure whether I should be impressed or horrified... [1] https://co

I posted this elsewhere in the thread, and don't want to spam it everywhere (or take away from Amla!), but you might be interested in eryx [1] - the Python bindings [2] get you a similar Python-in-Python sandbox based on a WASI build of CPython (props to the componentize-py [3] people)! [1]: https://github.com/sd2k/eryx/ [2]: https://pypi.org/project/pyeryx/ [3]: https://github.com/bytecodealliance/componentize-py/

Fully agree with your point here, but wanted to point out that including C dependencies is actually one of the biggest reasons why Python support is hard for WebAssembly too. Bolstering your point -- smart-and-hardworking people are working on this, which results in: https://github.com/bytecodealliance/componentize-py/ which inspired https://github.com/WebAssembly/component-model/blob/main/des... with some hard work done to make things work: https://github.com/dicej/wasi-wheels It's a fun ecosystem -- the challenge is huge but the work being done is really fundamentally clean/high quality, and the solutions are novel and useful/powerful.

The component model is already shipping in Wasmtime, and will be stable for use in Node.js and in browsers via jco (https://github.com/bytecodealliance/jco) soon. WASI Preview 2 will be done in December or January, giving component model users a stable set of interfaces to use for scheduling, streams, and higher level functionality like stdio, filesystem, sockets, and http on an opt-in basis. You should look at wit-bindgen (https://github.com/bytecodealliance/wit-bindgen) to see some of the languages currently supported, and more that will be mature enough to use very soon (https://github.com/bytecodealliance/componentize-py) Right now jco will automatically generate the JS glue code which implements a Component Model runtime on top of the JS engine's existing WebAssembly implementation. So, yes, Components are a composition of Wasm Modul

Thank you! To your point, the primary consideration for choosing the languages is their support for WebAssembly, and WASI in particular. Due to Spin's heavy use of WASI and the component model, languages that have first party support in the WIT bindings generator (https://github.com/bytecodealliance/wit-bindgen) are the easiest to implement, followed by languages that can be built on top of the support for those with first party support. For example, the JavaScript support is built by embedding QuickJS (in particular, Shopify's Javy project — https://github.com/fermyon/spin-js-sdk), which then uses the Rust SDK. (As a side note for the JS support — adapting QuickJS has been extremely helpful in getting JS support out; however, we are in the process of rebuilding the JS runtime using SpiderMonkey (with which a few people on the team have s