Wasmtime GitHub notifications bot (Mar 21 2023 at 22:25): Wasmtime GitHub notifications bot (Mar 21 2023 at 22:25):cpuguy83 opened issue #6083:
Hello, I'm reaching out on behalf of https://github.com/containerd/runwasi
In that project we a couple of crates which depend on wasmtime-fiber as a transitive dependency.Since wasmtime-fiber is linking native code this means it can only show up in the dependency graph once.
We unfortunately have two.
One is from wasmedge and the other from wasmtime which both depend on this crate for async support.
For now I've just disabled async support since we weren't using it anyway but do foresee wanting to add this later.I noticed this in wasmtime-fiber's Cargo.toml and was curious if this is feasible?:
Other alternatives we are looking at is just splitting these two crates out of the workspace and deal with managing the deps separately.
Wasmtime GitHub notifications bot (Mar 22 2023 at 14:14):alexcrichton commented on issue #6083:
Thanks for the report, but the
wasmtime-*family of crates that thewasmtimecrate depends on are not intended for general purpose reuse, so we've not committed to providing any degree of support for them. You're always welcome to fork the crates and publish under a different name (with license-appropriate attribution naturally). Additionally if you'd like to send a PR to the crate we can review that and merge that as well.
Wasmtime GitHub notifications bot (Mar 22 2023 at 14:48):cpuguy83 commented on issue #6083:
The reason I'm posting an issue is to discuss if the change proposed in the Cargo.toml is a valid/acceptable solution.
Wasmtime GitHub notifications bot (Mar 22 2023 at 15:23):pchickey commented on issue #6083:
The right solution here is that wasmedge should fork and publish wasmtime-fiber under a different name, with a different symbol under
links.
Wasmtime GitHub notifications bot (Mar 22 2023 at 18:29):Mossaka commented on issue #6083:
Hey I think @cpuguy83 is referring to the comment in Cargo.toml from
wasmtime-fiber, specifically# If this is an issue in the future we should tweak the build script to set `#define` # directives or similar to embed a version number of this crate in symbols.We are running into an issue where wasmtime-fiber show up in dependency graph twice as a transitive dep.
Wasmtime GitHub notifications bot (Mar 22 2023 at 19:03):pchickey commented on issue #6083:
I understand. That approach is technically possible for wasmtime-fiber to take, but it puts a significant burden on our release cycle to do so, and this isn't a problem that the wasmtime project created. Wasmedge took a dependency on wasmtime internals which makes it impossible for their code to co-exist with wasmtime, and so we believe the burden should be on wasmedge to correct this problem by forking and publishing the wasmtime-fiber crate under a different name.
Wasmtime GitHub notifications bot (Mar 22 2023 at 19:03):pchickey edited a comment on issue #6083:
I understand. That approach is technically possible for wasmtime-fiber to take, but it puts a significant burden on our release cycle to do so, and this isn't a problem that the wasmtime project created. Wasmedge took a dependency on wasmtime internals which makes it impossible for their crate to co-exist with wasmtime, and so we believe the burden should be on wasmedge to correct this problem by forking and publishing the wasmtime-fiber crate under a different name.
Wasmtime GitHub notifications bot (Mar 22 2023 at 19:11):jameysharp commented on issue #6083:
Right, but the reason it's showing up twice is because wasmedge-sys directly depends on wasmtime-fiber, which is not a usage we support. Specifically, they're depending on the crate from the Wasmtime 2.0 release, while you're using Wasmtime 7.0.
We're recommending that wasmedge should fork wasmtime-fiber and maintain their own copy with a different name, which will resolve the issue you're seeing.
Wasmtime GitHub notifications bot (Mar 22 2023 at 20:39):cpuguy83 commented on issue #6083:
Thanks for the quick responses.
Seems like this is not a desirable change for wasmtime so I'll go ahead and close this.Thanks again! :angel:
Wasmtime GitHub notifications bot (Mar 22 2023 at 20:39):cpuguy83 closed issue #6083:
Hello, I'm reaching out on behalf of https://github.com/containerd/runwasi
In that project we a couple of crates which depend on wasmtime-fiber as a transitive dependency.Since wasmtime-fiber is linking native code this means it can only show up in the dependency graph once.
We unfortunately have two.
One is from wasmedge and the other from wasmtime which both depend on this crate for async support.
For now I've just disabled async support since we weren't using it anyway but do foresee wanting to add this later.I noticed this in wasmtime-fiber's Cargo.toml and was curious if this is feasible?:
Other alternatives we are looking at is just splitting these two crates out of the workspace and deal with managing the deps separately.
Last updated: Dec 23 2024 at 13:07 UTC