Skip to content
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

Publish C API crate to crates.io #7735

Closed
maxbrunsfeld opened this issue Dec 31, 2023 · 2 comments
Closed

Publish C API crate to crates.io #7735

maxbrunsfeld opened this issue Dec 31, 2023 · 2 comments

Comments

@maxbrunsfeld
Copy link
Contributor

maxbrunsfeld commented Dec 31, 2023

Feature

It would be useful to me to be able to download wasmtime-c-api from crates.io, instead of from GitHub.

Benefit

I maintain a C library (Tree-sitter) that uses Wasmtime via the C API. Tree-sitter also has Rust bindings. The Tree-sitter Rust crate has a Cargo dependency on both wasmtime and wasmtime-c-api (previous discussion). Right now, those dependencies specify Git revisions, not version numbers, because wasmtime-c-api is not available on crates.io.

It would be useful if those two cargo dependencies could both be expressed in terms of version numbers, as opposed to git/rev dependencies. That way, consumers of tree-sitter would have more flexibility in terms of which versions of wasmtime were compiled into their binaries.

Implementation

It looks like there is automation for publishing various crates to crates.io, in the publish.rs script. I think that wasmtime-c-api could be added to the list of "public crates" which are published whenever a v tag is pushed.

Alternatives

  • Don't support this use case of combining C and Rust, since it's uncommon. If a C library depends on wasmtime, and that C library has Rust bindings, that Rust crate should not try to use Cargo to build and link Wasmtime.
  • Suggest that such crates should download and compile the wasmtime-c-api programmatically in a custom build script, as opposed to using a Cargo dependency.
  • Some other person or organization publish the wasmtime C API to crates.io. Don't do it as part of a Wasmtime workflow.
@alexcrichton
Copy link
Member

I think this is reasonable to support but one tricky bit will be that the name of the crate is wasmtime-c-api-impl right now where wasmtime-c-api is taken by the "artifact" which is a cdylib. That's what enables cargo build -p wasmtime-c-api in this repository to build the dynamic/shared library. This would probably want to be published as wasmtime-c-api to crates.io.

Otherwise though for a git dependency you should be able to use branch = 'release-16.0.0' for versioned releases, albeit only major versions and not between minor versions.

@maxbrunsfeld
Copy link
Contributor Author

Added in #7837.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants