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
andwasmtime-c-api
(previous discussion). Right now, those dependencies specify Git revisions, not versions, becausewasmtime-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 oftree-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 thatwasmtime-c-api
could be added to the list of "public crates" which are published whenever av
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.
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
andwasmtime-c-api
(previous discussion). Right now, those dependencies specify Git revisions, not version numbers, becausewasmtime-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 oftree-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 thatwasmtime-c-api
could be added to the list of "public crates" which are published whenever av
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 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 wherewasmtime-c-api
is taken by the "artifact" which is acdylib
. That's what enablescargo build -p wasmtime-c-api
in this repository to build the dynamic/shared library. This would probably want to be published aswasmtime-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 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
andwasmtime-c-api
(previous discussion). Right now, those dependencies specify Git revisions, not version numbers, becausewasmtime-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 oftree-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 thatwasmtime-c-api
could be added to the list of "public crates" which are published whenever av
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.
maxbrunsfeld commented on issue #7735:
Added in https://github.com/bytecodealliance/wasmtime/pull/7837.
Last updated: Dec 23 2024 at 12:05 UTC