-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plans to publish to crates.io? #180
Comments
200%, it will be incredibly useful to have the crates published |
Sorry I don't really have much more to add over what's already been said. It's naturally the goal to eventually publish to crates.io but at least personally I do not feel that this is ready. The component model itself is still very much in its infancy and trying to publish and maintain things before everything is ready runs a pretty high likelihood of generating more work for us than would otherwise be necessary. My personal goal is to integrate wit-bindgen well with the component model and today there's lots of pieces in wit-bindgen that could add up to that but as-is it's still pretty far away. There's no roadmap at this time, but me and many of my colleagues are focused on moving the component model forward, and |
Sadly my crate is using wit-bindgen's crates, and I cannot publish my crate since it's using the git urls as dependencies due to this project not being published yet. I hope this could be considered soon, the crates I'm using work great for my case |
A workaround is to just manually generate the code via the CLI or by using the relevant crate in a helper binary (like the xtask pattern. You can ensure that definitions stay up to date with a CI task that re-generates and fails if the diff is not empty. |
Interesting, I'll take a look into it thank you. |
@alexcrichton I noticed on crates.io that I definitely don't want to add more work to you or the rest of the bytecode alliance. Perhaps @Kylebrown9 and myself could handle the publishing aspect (that is ensuring the working GH action and that PRs adhere to conventional commits)? I'm currently publishing myself, but it would be nice for me and anyone else that wants to build out tools while being 100% comfortable with an unstable API to have an official crate. |
Oh I think actually For the publishing scripts I think it would ideally be possible to do something like wasm-tool's `publish.rs where it's just a script I run locally to do all the publication for all the various crates. Given that I'm happy to do the initial publish and I can setup a github team for publishers and would be happy to add others to it |
That sounds amazing! I would love to help in any way to push this project toward wider adoption! |
I know this project is still in its infancy and you are still iterating (#157 (comment)), but what would be the roadmap to publishing this project's crates to crates.io?
For context, I'm working on a
wit-bindgen
generator for WASM3, and was hoping to use crates.io dependencies instead of pinning to a specific git commit.I think the folks from wasmer might be in the same boat (wasmerio/wit-bindgen), except they chose to fork the
wit-bindgen
repository when writing theirwit-bindgen-wasmer
generator.The text was updated successfully, but these errors were encountered: