Taylor Thomas (Jun 15 2022 at 16:49): Taylor Thomas (Jun 15 2022 at 16:49):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?
Peter Huene (Jun 15 2022 at 17:09):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).
Peter Huene (Jun 15 2022 at 17:12):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.
Peter Huene (Jun 15 2022 at 17:14):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.
Taylor Thomas (Jun 15 2022 at 17:25):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
Ralph (Jun 16 2022 at 14:55):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.
Peter Huene (Jun 16 2022 at 17:19):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.
Peter Huene (Jun 16 2022 at 17:20):It might make sense to put it in wasm-tools, since I can envision this to be a generic component linker
Peter Huene (Jun 16 2022 at 17:22):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
theduke (Jun 22 2022 at 08:59):@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.
Bailey Hayes (Jun 22 2022 at 17:13):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.
Peter Huene (Jun 22 2022 at 17:14):Thanks for responding, Bailey :+1:
Peter Huene (Jun 22 2022 at 17:15):I'm currently out sick (pandemic finally caught me)
Bailey Hayes (Jun 22 2022 at 17:32):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
theduke (Jun 29 2022 at 12:59):I'll also add a somewhat delayed wish for a speedy recovery.
theduke (Jun 29 2022 at 13:00):Thanks for the info, I posted my proposal to the component-model repo.
Last updated: Nov 22 2024 at 17:03 UTC