Allow dynamic imports in sandbox example

[kyleconroy]

Allow dynamic imports in sandbox example

[dicej]

I just had a wild idea: we could optionally iterate over all known modules during pre-initialization and import them one by one (skipping any not currently supported like ssl). Not sure how much bloat that would add to the resulting component, but it would theoretically address this issue.

[kyleconroy]

With no imports, cli.wasm ended up being 33mb. After importing everything it was 43mb. Not too bad!

[dicej]

Yeah, that's not bad.

You probably already know this, but for anyone else reading: you can also import third-party packages (e.g. NumPy) the same way.

[dicej]

Thanks for reporting this, @kyleconroy. This sort of a duplicate of #23, but with a twist: wasmtime-py can't currently handle composed components (i.e. components that contain subcomponents), which is what wasi-virt generates, so the solution I proposed in that issue won't work until/unless wasmtime-py gains support for subcomponents.

An alternative approach would be to modify the sandbox example to allow access to a host-provided filesystem via wasi:filesystem, but then we hit another wasmtime-py limitation: no support for WASI (i.e. the wasmtime-wasi crate is only available for use in the Rust API for Wasmtime, not the Python one). It would certainly be possible to write a pure Python wasi:filesystem implementation that works with wasmtime-py, but it wouldn't be a quick task.

In short, we'd need to address this on both the componentize-py and wasmtime-py sides, and it will be a substantial amount of work. I don't expect I'll have time for it anytime soon, but I'd be happy to mentor anyone who wants to take a stab at it.

[kyleconroy]

You know, I was thinking the same thing as a workaround. Just add an import for every known module in the standard library. I can try that out and see how big the component becomes.

[dicej]

BTW, wasm-tools strip -a can reduce the component size quite a bit if desired.