Repository navigation
Expose rust crate? #160
Description
Activity
Hi @robalar. You can already use it as a Rust library crate using e.g.
componentize-py = { git = "https://github.com/bytecodealliance/componentize-py" }in your Cargo.toml file and then callingcomponentize_py::componentizein your code. Here's an example of doing that: https://github.com/dicej/wasi-sockets-tests/tree/main/server. See also CONTRIBUTING.md for instructions on installing a compatible version of WASI-SDK, which is needed to build the crate.The next steps for making that more ergonomic would be to start tagging releases in Git (which I should have been doing all along, but was lazy) and publishing the code on crates.io. The latter would require some extra work, because the build currently relies on the CPython submodule being present; we'd need to update the
build.rsto e.g. download a snapshot of the CPython repo and build that instead. Ideally, it would also download the appropriate WASI-SDK as well.TL;DR: It can be used as a Rust crate today, but needs a bit more work to install the native build deps automatically.
Oh nice! I must not have looked too hard for the exposed function 🤦 As for using a git dep, I've been burned before using them (cargo support isn't perfect) so ideally we'd get the code onto crates.io.
I can take a look at getting the
build.rsupdated if this is something you'd be interesting in reviewing.As for release process, could look at release-plz to automate all of the boring change tracking/versioning?
I can take a look at getting the
build.rsupdated if this is something you'd be interesting in reviewing.Sure, that would be great.
Hi there, great project!
I have a use case where I would like to build WASM components from user submitted source on a server. My thinking being the code used to power the CLI could also be exposed as a crate. Is this something you'd accept a patch for? or am I barking up the wrong tree and there is a better approach?
Would love to hear your thoughts, thanks!