Hey @Peter Huene you mentioned in https://github.com/bytecodealliance/wit-bindgen/pull/239 and https://github.com/bytecodealliance/wit-bindgen/pull/240 that wasmlink is no longer the thing to use, but I didn't see any sort of migration path for what to do next. Any suggestions?
Basically, I was about to release a blog post about using some components stuff and had used wasmlink to glue it all together (plus wit-bindgen-wasmtime to actually call a function). But all I saw was mention of the updated components model, which I can't use yet because the wasmtime dependencies of the bindgen stuff are still at 0.35 (pre component model support, which I don't think is in a released version of wasmtime yet?). Is there a way I can get things working with all of these new features?
Hi Taylor! A replacement for wasmlink
is definitely required and is very much on the short-term radar, but some design work is necessary to implement it properly (if you've seen Luke's earlier presentations on the component model to the WG, he discussed linker scripts to fully describe how dependencies get linked together; the design would mostly be in that space).
wasmlink
never worked with "components" since it predates the component model; it only operates on "core" wasm modules with the module linking proposal extensions; it had no way of representing the complex type system of components and so it had to inject adapter code in core wasm directly in the linked output to make things "work" with an unmodified wasmtime. Fundamentally, it was a tool to show off the vision long before we had a standards proposal to go off of.
As things stand today, we have tooling around creating actual wasm components (I'm about to open up cargo-component
to make it easy to in Rust) and there's quite a bit of progress from Alex in implementing executing single components (passing in complex data, getting complex data out). He's now actively working on nested component instantiation which will move us towards being able to use a fully linked component graph, so it makes sense we'd want a tool to create one very soon.
If you want to show off what you could do with wasmlink, I think you'll have to stick with wasmlink and older versions of the other tools (current wasmtimes can't even run the output of wasmlink as module linking support was removed).
We're unfortunately in that place right now where we're not back to basic parity with the former tooling, but maintaining the former tooling and it's reliance on proposals we're not moving forward on has become burdensome.
Once we had a component model proposal and its ability to describe how component functions get lifted from or lowered to core wasm functions, a heck of a lot of functionality of wasmlink
was immediately made unnecessary, so it was pretty obvious that it wasn't the tool needed for the future.
Ok, that makes sense. I think I'll go forward with our wasmlink examples and explicitly call out that there is a new thing coming
Hi @Peter Huene, is there a location where we might begin to help bring a witlink
forward a bit? Sometime contributions help, and sometimes they hinder. Just curious how you and Alex see it.
Work hasn't started on it yet, so there isn't one at the moment. It also probably won't be called witlink
as it likely won't be dependent on wit at all, just components and some sort of script that describes how to generate a new component that links together all the components referenced in the script.
It might make sense to put it in wasm-tools
, since I can envision this to be a generic component linker
For what it's worth, I think I'm at the point where I can dedicate my time to moving this forward, but I'd definitely appreciate help and design input
@Peter Huene side question: is the .wit
format still intended to be official and defined by the component model specification? The current repo doesn't mention wit at all.
I'm asking because I'd like to propose the addition of custom annotations that could be used by code generators, but I'm not sure where the best place for that is now.
We're considering standardizing wit #484 as a part of the component model. At the moment, wit and wit-bindgen are really their own thing that evolved with the component model proposal.
I think creating an issue on the component model repo is a good place to start for this proposal.
Thanks for responding, Bailey :+1:
I'm currently out sick (pandemic finally caught me)
Sorry to hear! I hope you feel better soon. @Kyle Brown and I have been ramping on wit, wit-bindgen, and component model so I know enough to be dangerous. Holler if there's anything we can pick up
I'll also add a somewhat delayed wish for a speedy recovery.
Thanks for the info, I posted my proposal to the component-model repo.
Last updated: Dec 23 2024 at 14:03 UTC