How do we feel about wasmtime-wasi
re-exporting cap-std
and wasi-cap-std-sync
? As a wasmtime embedder that is configuring WASI, it is quite annoying to wrangle all these types and dependencies from different crates.
Also, ideally I would just be able to call wasi_ctx_builder.preopen_dir(path_to_dir, path_to_expose_it_as)
without needing to actually do the preopen myself before passing it to the builder (which is where all these other deps start coming in).
Are we cool with these API additions? If so, I can whip up a PR.
cc @Dan Gohman @Pat Hickey
cap-std is ok with that; it's public interface is closely tied to std's interface, so it's pretty stable
I'm less confident about wasi-cap-std-sync, though I don't have specific concerns I can articulate
wasi-cap-std-sync's traits are likely to evolve, but maybe that's ok
i think its fine to re-export them using a cargo feature.
the reason cap-std-sync is a separate crate is that one day cap-std-async will exist.
so, if wasmtime-wasi wants to export wasi-cap-std-sync::WasiCtxBuilder as sync::WasiCtxBuilder, thats cool.
it can be a default feature, it is just something that some embedders (read: me, one day soon) may want to turn off
the usability right now is not good at all, and re-exporting would go a long way to improve that - make the way you are supposed to use it obvious for users who dont know the whole twisty network of crates and future plans.
what about not doing the re-exporting, but having the preopen_dir
builder method do the preopening, rather than taking an already preopened dir? that would eliminate the need to worry about deps completely, afaik
Is there a downside to reexporting? Regardless of their stability they're a public dependency of wasmtime-wasi
and I think fitzgen's got a good point that wrangling a bunch of crates with disparate versions isn't the most enjoyable thing to do
although I think ideally we'd refactor the wasmtime-wasi crate to have an api which has fewer transitive crates as public dependencies
Yea we can fold the preopening into the builder so all Wasmtime-wasi has to re-export is the builder.
@fitzgen (he/him) should i make those changes to wasmtime-wasi or will you?
if you have cycles now, go for it, I'm a bit busy making benchmarks/demos for my wasm summit talk at the moment
ok. ill take care of it in a little bit. im on openssl 1.1.1k duty right now, apparently
thanks!
quick question: wasmtime_wasi::Wasi::new
still takes a store as a parameter, but I want to add it to a Config
, not a Linker
. Can I just use a dummy store?
hm wait but I can't make a Store
yet because I'm still building the Config
for my Engine
...
Oh sorry, I missed this convo. Yeah, with Wasi::add_to_config
you call Wasi::set_context
to set the WasiCtx in the store
i agree it's pretty confusing having two ways to do this
when using the functions defined in a config, we never actually create an instance of Wasi
which itself is just a holder of Func
okay, got everything working now, thanks :)
make sure you do store.add(Rc::new(RefCell::new(wasi_ctx))
or else it will fail at runtime
Wasi::set_context
encapsulates that
oh cool
idk why i didnt see that, you said it right there
i blame openssl
:shakes fist at openssl:
https://github.com/bytecodealliance/wasmtime/pull/2776
Last updated: Dec 23 2024 at 14:03 UTC