Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow dynamic imports in sandbox example #91

Open
kyleconroy opened this issue May 1, 2024 · 6 comments
Open

Allow dynamic imports in sandbox example #91

kyleconroy opened this issue May 1, 2024 · 6 comments

Comments

@kyleconroy
Copy link
Contributor

I'd like to execute code using the sandbox example, but am running into an issue. I want to allow exec'd code to import packages, but if I don't import packages in the host script, the guest code won't run.

# Guest code
import json

print(json.dumps({"message": "Hello"}))
# Works
import sys
import json

from command import exports

class Run(exports.Run):
    def run(self):
        with open(sys.argv[1]) as f:
            code = f.read()
            exec(code)
# Fails
import sys

from command import exports

class Run(exports.Run):
    def run(self):
        with open(sys.argv[1]) as f:
            code = f.read()
            exec(code)
@dicej
Copy link
Collaborator

dicej commented May 1, 2024

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.

@dicej
Copy link
Collaborator

dicej commented May 1, 2024

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
Copy link
Contributor Author

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.

@kyleconroy
Copy link
Contributor Author

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

@dicej
Copy link
Collaborator

dicej commented May 1, 2024

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
Copy link
Collaborator

dicej commented May 1, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants