I was wondering whether I should use https://github.com/dicej/component-init instead of wizer for my project, is component-init meant to stay or is that a temporary proof of concept repo?
I'll try using it and see how far I get :)
I wrote that specifically for https://github.com/dicej/componentize-py, but @Guy Bedford is interested in using it elsewhere, so I moved it into its own repo. So yes, it's meant to stay and evolve into something more general. Let me know if I can help make it work better for your use case.
thank you for answering :)
so the product I want to port to wasm consists of a python library for legacy reasons and customer-facing js.
I got rquickjs to compile for wasi with a few patches and used wlr-libpy to get pyo3 linked too, I tried to use the same approach as the main branch of componentize-py for my module but I got stuck at preopening the Dir, my wizer.initialize function does not see the mapped directories, so I thought maybe it's better to switch to the component model too
the wasm component is already statically linked so I think I only need to adapt the component and then basically use component_init as in the componentize-py snapshot branch, I think?
Not sure why your wizer.initialize function couldn't see the mapped directories -- I've never had an issue with that. You might want to double-check that you configured Wizer correctly (i.e. used Wizer::map_dir
and specified the correct guest path(s)).
https://github.com/dicej/componentize-py/blob/main/src/lib.rs#L152
I tried to do exactly what the main branch does here
oh also, is my assumption correct that wizer or component-init includes the preopened files in the final output component? Or does that happen somewhere else?
Yeah, componentize-py
's main branch uses a hacky workaround for the fact that Wizer doesn't provide fine-grained control over the WASI context. Specifically, I wanted specific control over the set of environment variables passed to the guest, whereas Wizer only provides an inherit_env
function. But yeah, that hack should work in your case, too.
Regarding preopened files: neither Wizer nor component-init will make the preopened files available in the output -- you need to use e.g. wasi-vfs
(or wasi-virt
, when it's ready) for that. componentize-py
is currently cheating a little by assuming that the app being pre-initialized will read and parse all the files it needs during pre-init and not need to read from the filesystem again at runtime (or at least not from the same set of files that were available during pre-init). That won't work in general, so eventually I expect componentize-py
will use wasi-virt
.
ah ok, so to get my current thing running I need to provide the dir to be mapped during runtime but I'll definitely look into wasi-virt and vfs, thanks a lot, I wouldn't have got this far without your code as reference :)
Last updated: Dec 23 2024 at 12:05 UTC