jedisct1 commented on Issue #2573:
@pchickey that would indeed be much cleaner.
The paths have been updated to that layout.
jedisct1 commented on Issue #2573:
Unfortunately, with that layout,
wasi-crypto
becomes part of the workspace, which doesn't allow different versions of the same dependency.And some of our existing code requires
rand_core 0.6
, butwasi-crypto
dependencies requirerand_core 0.5
:(
pchickey commented on Issue #2573:
Duplicate dependencies are a mild bummer, and worth the win of having everything in one workspace. thanks!
pchickey edited a comment on Issue #2573:
Duplicate
rand
dependencies are a mild bummer, and worth the win of having everything in one workspace. thanks!
jedisct1 commented on Issue #2573:
Unfortunately having different versions appears to be a little bit more than a mild bummer on Windows.
I'm gonna send PRs to have these dependencies updated for
rand_core
0.6.
jedisct1 commented on Issue #2573:
The implementation can certainly be moved back to the
wasi-crypto
repository, leaving only the integration bits here.But it itself requires
wiggle
. Which is fine, untilwasmtime
's internalwiggle
version diverges from thecrates.io
version.
Should thewasi-crypto
implementation include the entirewasmtime
tree as a submodule just to get itswiggle
version?The implementation is also compatible with
lucet
, but matching thewiggle
version has also always been an issue.What would be a way to solve this?
pchickey commented on Issue #2573:
We've struggled with that in
wasi-common
as well and in the ongoing rewrite, one of the biggest wins we had was breaking out a lot of the implementation into thecap-std
family of crates, which take no dependency onwiggle
or other Wasmtime project components. Doing this properly required a lot of design work, including introducing the separation of mutable and immutable borrows into wiggle, but ultimately I think it was worthwhile.cap-std
defines its own structs, flags, enums and so on, and in many ways these mirror the ones thatwiggle
can generate from the wasi witx files. In thewasi-common
library weimpl From
to convert back and forth between these types, which is a little noisy, but we trust LLVM to compile these trivial impls down to no-ops, and worthwhile to break the complexity.Maybe we could spend some time pair programming this week to figure out how an analogous split would work for wasi-crypto?
jedisct1 commented on Issue #2573:
This is very helpful, thanks!
And thanks for offering some pair programming time. That may indeed be very useful. I'm going to work on splitting the current
wasi-crypto
code to see what it takes first.Thanks to Alex and you!
Last updated: Dec 23 2024 at 12:05 UTC