Stream: git-wasmtime

Topic: wasmtime / issue #7735 Publish C API crate to crates.io

Wasmtime GitHub notifications bot (Dec 31 2023 at 19:18):

maxbrunsfeld opened issue #7735:

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 versions, 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.

Wasmtime GitHub notifications bot (Dec 31 2023 at 19:19):

maxbrunsfeld edited issue #7735:

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.

Wasmtime GitHub notifications bot (Jan 02 2024 at 20:10):

alexcrichton commented on issue #7735:

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.

Wasmtime GitHub notifications bot (Feb 05 2024 at 19:01):

maxbrunsfeld closed issue #7735:

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.

Wasmtime GitHub notifications bot (Feb 05 2024 at 19:01):

maxbrunsfeld commented on issue #7735:

Added in https://github.com/bytecodealliance/wasmtime/pull/7837.

Last updated: Dec 13 2025 at 21:03 UTC