Wasmtime GitHub notifications bot (Jan 29 2024 at 01:30): Wasmtime GitHub notifications bot (Jan 29 2024 at 01:30):maxbrunsfeld requested alexcrichton for a review on PR #7837.
Wasmtime GitHub notifications bot (Jan 29 2024 at 01:30):maxbrunsfeld opened PR #7837 from maxbrunsfeld:publish-c-api to bytecodealliance:main:
Prior discussion: https://github.com/bytecodealliance/wasmtime/issues/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.
Currently, the package name is
wasmtime-c-api-impl(sincewasmtime-c-apiis used by the cdylib). That seems fine to me, but I'm also open to some name change.
Wasmtime GitHub notifications bot (Jan 29 2024 at 01:30):maxbrunsfeld requested wasmtime-default-reviewers for a review on PR #7837.
Wasmtime GitHub notifications bot (Jan 29 2024 at 01:37):maxbrunsfeld edited PR #7837:
Prior discussion: https://github.com/bytecodealliance/wasmtime/issues/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(sincewasmtime-c-apiis used by the cdylib). That seems fine to me, but I'm also open to some name change.
Wasmtime GitHub notifications bot (Jan 29 2024 at 22:27):Wouldn't this line here need to be removed? I could be totally wrong
Wasmtime GitHub notifications bot (Jan 29 2024 at 23:50):alexcrichton commented on PR #7837:
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.mdexplaining 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.
Wasmtime GitHub notifications bot (Jan 30 2024 at 00:40):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Jan 30 2024 at 00:40):maxbrunsfeld requested wasmtime-core-reviewers for a review on PR #7837.
Wasmtime GitHub notifications bot (Jan 30 2024 at 01:06):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Jan 30 2024 at 01:13):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Jan 30 2024 at 01:29):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Jan 30 2024 at 01:55):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Jan 30 2024 at 02:01):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Jan 30 2024 at 02:09):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Jan 30 2024 at 02:11):maxbrunsfeld commented on PR #7837:
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.rsthat provideslinksmetadata. 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-apiREADME 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.
Wasmtime GitHub notifications bot (Jan 30 2024 at 02:11):maxbrunsfeld edited a comment on PR #7837:
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.rsthat provideslinksmetadata. 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-apiREADME 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.
Wasmtime GitHub notifications bot (Jan 30 2024 at 03:44):github-actions[bot] commented on PR #7837:
Subscribe to Label Action
cc @peterhuene
<details>
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 <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Jan 31 2024 at 02:02):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Feb 02 2024 at 17:15):ping @alexcrichton @peterhuene, this would be immensely helpful for tree-sitter to have the C API published to crates.io :sweat_smile: since this is a blocker for us to publish the latest release on crates.io
Wasmtime GitHub notifications bot (Feb 02 2024 at 17:54):maxbrunsfeld commented on PR #7837:
I just realized I could test this with
dry-runpublishing, and that thewasmtime-c-api-macroswould need to be published as well. I think that the most straightforward way to do that would be to move it up to thecratesfolder 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.
Wasmtime GitHub notifications bot (Feb 02 2024 at 18:42):alexcrichton submitted PR review:
Looks good to me, thanks! I suspect that the
publish.rsmay need reordering though as well, yeah. If you addprtest:fullto 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.
Wasmtime GitHub notifications bot (Feb 02 2024 at 18:43):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Feb 02 2024 at 18:51):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Feb 02 2024 at 18:56):maxbrunsfeld commented on PR #7837:
Ah ok, I'll do that. Thanks for responding while you're all traveling.
Wasmtime GitHub notifications bot (Feb 02 2024 at 19:56):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Feb 02 2024 at 20:05):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Feb 05 2024 at 16:29):alexcrichton commented on PR #7837:
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.
Wasmtime GitHub notifications bot (Feb 05 2024 at 17:21):maxbrunsfeld updated PR #7837.
Wasmtime GitHub notifications bot (Feb 05 2024 at 17:42):alexcrichton has enabled auto merge for PR #7837.
Wasmtime GitHub notifications bot (Feb 05 2024 at 18:48):alexcrichton merged PR #7837.
Wasmtime GitHub notifications bot (Feb 05 2024 at 18:50):maxbrunsfeld commented on PR #7837:
Thanks so much @alexcrichton.
Just curious - Now that this is landed, would it be easy to publish to crates.io the C-API corresponding to the latest published
wasmtimeversion, or do we need to wait until the next Wasmtime release?
Wasmtime GitHub notifications bot (Feb 05 2024 at 18:51):maxbrunsfeld edited a comment on PR #7837:
Thanks so much @alexcrichton.
Just curious - Now that this is landed, would it be easy to publish to crates.io the
wasmtime-c-api-implcorresponding to the latest publishedwasmtimeversion, or do we need to wait until the next Wasmtime release?
Wasmtime GitHub notifications bot (Feb 05 2024 at 18:56):alexcrichton commented on PR #7837:
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.0has what was released in January and just todayrelease-18.0.0was created to be released in two weeks. This PR landed onmainwhich will becomerelease-19.0.0which 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.
Wasmtime GitHub notifications bot (Feb 05 2024 at 19:00):maxbrunsfeld commented on PR #7837:
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?
Wasmtime GitHub notifications bot (Feb 05 2024 at 19:07):alexcrichton commented on PR #7837:
Indeed that's all that's required, and please feel free!
Wasmtime GitHub notifications bot (Feb 05 2024 at 19:20):maxbrunsfeld commented on PR #7837:
Ok, PR up: https://github.com/bytecodealliance/wasmtime/pull/7872
Last updated: Nov 22 2024 at 16:03 UTC