# WASI Update https://opensource.snarky.ca/ --- ## What is [WebAssembly](https://webassembly.org)? - Virtual ISA - Fast to verify - Fast to compile to native - The "Web" part is historical artifact; used anywhere safety/portability is important - Browser, IoT/SoC, functions-as-a-service (FaaS), plug-in systems - [W3C spec](https://www.w3.org/TR/wasm-core/) --- ## What is [WASI](https://wasi.dev)? - Think CORBA - Used to be more like POSIX for WASM - Component model defines how to plug WASM components together - Used in non-browser contexts (although works there as well) - Run by the [Bytecode Alliance](https://bytecodealliance.org) - Is a [W3C subgroup](https://github.com/WebAssembly/WASI/blob/main/Charter.md) --- ## How to build for WASI? - Get the appropriate* [WASI SDK](https://github.com/WebAssembly/wasi-sdk) - [Download](https://github.com/WebAssembly/wasi-sdk/releases) - [Dev container image](https://github.com/python/cpython-devcontainers/tree/main/devcontainer) ```shell py Tools/wasm/wasi build --quiet -- --with-pydebug -C ``` - Builds ends up in a `cross-build` subdirectory of your checkout - [Documented in the devguide](https://devguide.python.org/getting-started/setup-building/#wasi) --- ## "Quirks" of the WASI SDK - It's clang with [wasi-libc](https://github.com/WebAssembly/wasi-libc) baked in as sysroot - Inconsistent release schedule (basically as needed) - Wasi-libc is **NOT** forwards or backwards compatible --- ## Planned support plan - Lock a Python version to the latest WASI SDK that works when a1 is released - Keep that as the supported version for its entire support lifetime - Currently slated to be [WASI SDK 25](https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-25) for 3.15 due to [bug in WASI SDK 26](https://github.com/WebAssembly/wasi-libc/issues/617) and newer - WASI version support will be based on the WASI SDK version support and what happens to be supported by RC --- # ❓ ### Install 5 WASI SDK versions into the dev container? [^1] - **Yes**: install all relevant WASI SDK versions in the dev container - **No**: separate WASI dev container w/ all versions - **Sort of**: WASI SDK for `main` in main dev container, rest in separate container --- # ❓ ## Keep WASI in `Tools/wasm`? [^2] - Yes - No, make top-level like `Android`, `Mac`, `PC`, `iOS` ### Applies to Emscripten? --- # ❓ ## Can we do binary releases of WASI? [^3] - I plan to add a `wasi package` command - I want to figure out how to use https://github.com/python/cpython-source-deps w/ a `wasi externals` command - I will be talking more about this later ... 🔮 --- # ❓ ## What's missing? [^4] - What do you all want to make WASI easier to work with? - There's a ["os-wasi" label](https://github.com/python/cpython/labels/OS-wasi) on GH - MAL has an [idea for a `.devcontainer/compose.yml`](https://github.com/python/cpython/issues/135693) - My plans are at https://opensource.snarky.ca/Python/WASI/Plans [^1]: Consider doing a minimal/slim dev container for those that are concerned about size, otherwise include everything. [^2]: Talk to the SC (or start topic on DPO) about a `Platforms/` directory to consolidate, otherwise Russell has a PR to consolidate Apple-related platforms under `Apple/`, so we could do `wasm/`. [^3]: Yes! [^4]: No feedback.