wasmedge-quickjs is also a bit of a problematic dependency.

It works under the current wasmedge CLI-based paradigm. However, switching to the wasmtime CLI won't work at all (lots of errors about unimplemented or incorrectly implemented WASI hooks).

Interestingly, when we run our wasmedge-quickjs binaries under the Rust prototype, they almost work. We just have to adjust the signature for the sock_accept binding to accept three i32s instead of two. It's annoying, but this process can be automated in CI so long as we keep a patch file up to date.

I've tried moving to the upstream quickjs and building .wasm with wasi-sdk. I tried building this with both the release version and by building wasi-sdk from source. Neither worked, even with some jiggling of clang flags. I think this is possible but would ultimately be a lot more work than maintaining a patch file (and it's a MUCH longer process, to boot).

Other things we could try:

• follow these instructions to build quickjs with cmake, but use emscripten instead of cmake;
• try this vaguely suspicious-looking wasmer/wasmtime/quickjs build?

A note that RustPython with wasm32-wasip1 does work under the Rust prototype (running wasmtime's Rust bindings), so that should no longer be a concern if we switch to Rust.