Allow using WASI APIs in the Python extension #533
Conversation
crates/interface-types/src/lib.rs
Outdated
| for import in section { | ||
| let import = import?; | ||
| match import.module { | ||
| "wasi" | "wasi_unstable" => { |
There was a problem hiding this comment.
Note that this logic was lifted up from below to work for modules that don't have an interface types section as well.
There was a problem hiding this comment.
wasi_snapshot_* will soon be becoming a thing, so we should add .starts_with("wasi_snapshot_*") here too.
There was a problem hiding this comment.
Sure yeah, I went ahead and refactored this a bit as well to hopefully future proof slightly. I think to support multiple wasi interfaces we'll need a bit more logic with wasmtime-wasi anyway.
|
I believe the failure here is because our builds require glibc 2.6 due to our usage of the I'll look into fixing this on Monday. |
alexcrichton
force-pushed
the
python-wasi
branch
from
43c1254 to
dd577b9
Compare
|
Yay green CI! This shouldn't be merged, however, until #535 is merged and I rebase on that. |
This commit adds support to the Python extension to load the WASI implementation when a WASI module is seen allowing Python to load WebAssembly modules that use WASI. This is pretty primitive right now because there's no way to configure the environment/args/preopens/etc, but it's hoped to be at least a start!
* Move the check into `wasmtime-wasi` itself * Make it conservative for now and match anything that says `wasi*` * Leave a `FIXME` for improving this later on
alexcrichton
force-pushed
the
python-wasi
branch
from
dd577b9 to
3d2f8a5
Compare
|
Ok should be good to go now! |
This commit adds support to the Python extension to load the WASI
implementation when a WASI module is seen allowing Python to load
WebAssembly modules that use WASI. This is pretty primitive right now
because there's no way to configure the environment/args/preopens/etc,
but it's hoped to be at least a start!