Add wasmtime-c-api-impl to the list of crates to publish

[maxbrunsfeld]

Prior discussion: #7735

Having the C API available on crates.io is useful for crates that use C code that use Wasmtime via the C API, allowing those crates themselves to be published to crates.io.

I'm not sure if there are drawbacks to adding this; I just thought I'd open this PR as a concrete suggestion, in case it's uncontroversial.

Currently, the package name is wasmtime-c-api-impl (since wasmtime-c-api is used by the cdylib). That seems fine to me, but I'm also open to some name change.

[amaanq]

Wouldn't this line here need to be removed? I could be totally wrong

wasmtime/crates/c-api/Cargo.toml

Line 10 in 94b3e84

publish = false

[alexcrichton]

Thanks! I don't have a great suggestion for how to fix the namig problem, and it's probably not worth holding this up for fixing that.

In addition to @amaanq's suggestion would you be up for helping spruce up the documentation a bit? For example I think it'd be good to have some basic crate documentation explaining what things are (as nothing has rustdoc internally otherwise) and ideally we'd also have a README.md explaining a bit about how to use it (as that'll get rendered on crates.io). I also think it'd be good to have a written log about how the crate is used so if we change things in the future we know what to keep working.

[maxbrunsfeld]

Ok, I updated the Cargo metadata, enabling publishing and documentation. In order to make it convenient for a downstream crate to include wasmtime's headers, I also added a small build.rs that provides links metadata. The resulting environment variables worked as expected for me in my downstream crate (tree-sitter) when I pull the crate from GitHub. I think that means that they will work when the source is pulled from crates.io, but it's possible I've made a mistake there.

I added some content to the c-api README about how to consume the crate from Rust, in the case where you're binding to a C library that uses wasmtime.

I also added a bit to the module-level doc comment for c-api.

Let me know if there were other forms of documentation that make sense for this.

[github-actions]

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:c-api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:c-api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[amaanq]

ping @alexcrichton @peterhuene, this would be immensely helpful for tree-sitter to have the C API published to crates.io 😅 since this is a blocker for us to publish the latest release on crates.io

[maxbrunsfeld]

I just realized I could test this with dry-run publishing, and that the wasmtime-c-api-macros would need to be published as well. I think that the most straightforward way to do that would be to move it up to the crates folder and add it to the Cargo workspace. I'm going to proceed with doing that on this branch. Let me know if I'm missing something there, and there's a different solution to that macros thing.

[alexcrichton]

Looks good to me, thanks! I suspect that the publish.rs may need reordering though as well, yeah. If you add prtest:full to a commit message in this PR it'll run the full CI if you'd like (before it goes to the merge queue)

Note that most of the Wasmtime team has been at the BA plumbers summit this week and is traveling home today.

[maxbrunsfeld]

Ah ok, I'll do that. Thanks for responding while you're all traveling.

[alexcrichton]

Ah apologies now that I've gotten back to this it now has a merge conflict. If you don't mind rebasing again I'll add it to the merge queue. Otherwise though I can do the rebase/merge later this week.

[maxbrunsfeld]

Thanks so much @alexcrichton.

Just curious - Now that this is landed, would it be easy to publish to crates.io the wasmtime-c-api-impl corresponding to the latest published wasmtime version, or do we need to wait until the next Wasmtime release?

[alexcrichton]

Doing this for the current release would require a backport and we typically try not to backport features and instead only backport bugfixes. Not impossible but if you're ok I think this would be best to wait.

That being said there's three active branches at the moment. release-17.0.0 has what was released in January and just today release-18.0.0 was created to be released in two weeks. This PR landed on main which will become release-19.0.0 which will be released in March. If you'd like I think it's ok to backport this to the 18.0.0 release branch if you'd prefer to have this in a release sooner rather than later.

[maxbrunsfeld]

Got it. I would love to backport to 18.0 if possible. Is that something I can help with, via a PR against that branch?

[alexcrichton]

Indeed that's all that's required, and please feel free!

[maxbrunsfeld]

Ok, PR up: #7872