Get async options from package metadata

[justingaffney]

Not sure if it would be preferred to have wit_bindgen_rust::AsyncConfig implement serde::Deserialize, instead of creating a copy of the enum in this repo that implements it.

But I figured it is still useful to allow configuring the async options in cargo-component in the meantime, and remove the enum copy if wit_bindgen_rust::AsyncConfig implements it in the future

[pchickey]

Can this wait to land until we depend on a new wasm-tools that has the serde::Deserialize impl? That seems like a good change to make over there.

[justingaffney]

Sure no problem. Do you mean wit-bindgen, or am I misunderstanding? I think implementing serde::Deserialize here is all that is needed https://github.com/bytecodealliance/wit-bindgen/blob/19a2351e3e2fa821f2393411ff7f76c40d65a92d/crates/rust/src/lib.rs#L136-L145

[pchickey]

Yes, my bad, I got it mixed up. Can you add a PR to add an optional non-default serde feature to the wit-bindgen-rust crate that adds derives for all of the structs/enums in the public interface, along the same lines as the clap::Parser derives in there now. Then I can cut a wit-bindgen release and we can pull that in here.

[justingaffney]

bytecodealliance/wit-bindgen#1244 is merged now, once the new wit-bindgen release is out I'll update this PR

[justingaffney]

According to issue #387, due to refactoring around futures/streams it might not be possible to update the version of wit-bindgen that cargo-component uses, without requiring users to update the wit-bindgen-rt dependency in their projects to match.

Would it be possible to cut a wit-bindgen release at this commit bytecodealliance/wit-bindgen@c30dc9a? This is just before the refactor got merged and would contain the serde::Deserialize implementations for bindgen options, as well as some recent bug fixes around future/stream code generation. Then cargo-component can get updated to use this new version until #387 is resolved.

[pchickey]

wit-bindgen uses an automated workflow for releases that can only create a new version from the head of main, and I don't want to deviate from using that unless we have a very strong motivation (security or critical bugfix). For everything related to async component model, I don't want to tie us up in knots trying to make releases just right, especially for end-user tools like cargo-component, since the spec and implementations are still moving fast and breakages are very frequent. So, if you do need to pin at certain versions, I suggest that you make forks and/or use cargo patches to create the packages you need.

Cargo component is an early experiment on what DX for components could look like, and it was very successful in being an experiment in that it informed a suite of follow-on work. Unfortunately it lost its dedicated maintainer about a year ago and hasn't kept up to date, and will need major renovations to become a more useful tool and will necessarily break existing users in the process. I know that breakages (or plans for breakages soon) are not fun to deal with, but in the early stages of an ecosystem it is unfortunately necessary to make progress, and when we cross that with keeping up on the latest and greatest developments in the ecosystem, it gets too complicated for our small team to keep up with providing stability in some ways and the latest and greatest in other ways.

[justingaffney]

I personally don't have any problem with updates to cargo-component breaking backward compatibility I understand it is experimental and the async stuff is moving quickly, I just assumed based on the other issue I linked that the preference was to keep things backward compatible.

Would it then still be ok to update cargo-component to use the next wit-bindgen release? If not I am happy to just update my fork and use it to build components. I find cargo-component convenient to use, and I am running into issues experimenting with WIT futures and streams when building components with just wit-bindgen and the wasm32-wasip2 rust target (I think because the version of wasm-component-ld it uses does not have any of the async support in it yet?)

[pchickey]

If you're building async components before they stabilize I suggest that you maintain your own build of cargo-component which provides a wit_component::ComponentEncoder (provided directly by cargo-component, but ships in rust as wasm-component-ld) which is from the same wasm-tools release as all the other pieces of your toolchain and runtime - otherwise you will run into binary compatibility issues, since the binary format is changing nearly every wasm-tools release.

We don't have the bandwidth to keep up with those frequent changes in this project at this time, and we don't really consider it desirable either, since we really don't want users who aren't able to grok all the bits of the toolchain and keep them up themselves using async components yet, since they are still very much WIP and breaking constantly.

[justingaffney]

No problem, that is fair enough. I'll close this PR then and use my own build, and try keep it up to date until async components stabilise. Thanks!