Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Wasm to hash dep components, rather than tar #25

Open
rvolosatovs opened this issue Apr 12, 2023 · 3 comments
Open

Use Wasm to hash dep components, rather than tar #25

rvolosatovs opened this issue Apr 12, 2023 · 3 comments

Comments

@rvolosatovs
Copy link
Member

rvolosatovs commented Apr 12, 2023

Refs #24

Instead of tar-packing the dependencies to compute the digest, use https://github.com/bytecodealliance/wasm-tools to assemble a Wasm containing all the interfaces and worlds within the fetched package and hash that.
For a given dependency X, produce deps/X.wasm alongside deps/X directory for backwards compatibility at least until the released version of https://github.com/bytecodealliance/wit-bindgen can take Wasm as input

  • Given the state of tooling today, it appears that WIT package->Wasm direction is covered, what about Wasm->(expanded) WIT package?
@rvolosatovs rvolosatovs changed the title Use WASM to hash dep components, rather than tar Use Wasm to hash dep components, rather than tar Apr 12, 2023
@esoterra
Copy link

I think the part I would tackle first is just enhancing wit-deps to generate a single Component binary for the current wit directory and all the fetched deps.

Then we can start using this to publish interface packages (as binaries) to GitHub artifacts and eventually a registry.

Once we start having binaries for packages built using CI/CD available somewhere, it makes sense to then add the ability to take those as an input for dependencies.

@rvolosatovs
Copy link
Member Author

I think the part I would tackle first is just enhancing wit-deps to generate a single Component binary for the current wit directory and all the fetched deps.

Then we can start using this to publish interface packages (as binaries) to GitHub artifacts and eventually a registry.

Once we start having binaries for packages built using CI/CD available somewhere, it makes sense to then add the ability to take those as an input for dependencies.

i.e. #24

@esoterra
Copy link

Ah, missed the refs #24. My bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants