Hey all, I'm using cargo component v0.15.0, and I can't seem to tell it to ignore the registry setting. My commands for a basic usage:
wkg oci pull ghcr.io/webassembly/wasi/http:0.2.0
wasm-tools component wit webassembly_wasi_http.wasm --out-dir wit
cargo component new --proxy hello-wasi-http --lib -t wasi:http/proxy
now, with the last command I receive the following:
error: a default component registry has not been set
the help doesn't really specify whether registry means the registry you'll pull from (the future embedded usage of wkg
for exmaple) or where I'm going to PUSH the resulting component. So I look in the repo (https://github.com/bytecodealliance/cargo-component/blob/main/docs/design/registries.md) it says, "The registry
field is optional and defaults to default
(see the [package.metadata.component.registries]
table below).`
there's an extensive discussion below, but if I'm going to specify --registry
is this supposed to be pointing at ghcr.io/webassembly/wasi/http:0.2.0
????
trying to tie the current implementation together with a straightforward workflow.
@Ralph Yeah this is still a work in progress. We are close to getting done with adding pulling from a registry: https://github.com/bytecodealliance/cargo-component/pull/322
There will still be some follow ups after that but we're getting there
Our goal is to have a mirror setup from wasi.dev pointing to ghcr.io/webassembly/wasi packages.
While the OCI workflow is baking, you can set packages like: https://github.com/sunfishcode/hello-wasi-http/blob/main/Cargo.toml#L20-L27. A while back it changed from using a wit dir to this syntax.
OK, so I still have a problem and would love to walk it through with someone if they have ten minutes
I do cargo component new --lib --proxy hello-wasi-http
and that gets me a simple buildable version of hello but that is NOT wasi components yet.
so I then download the oci package, and use wasm-tools to generate a directory that comes out like this, flatter than before and in Dan's example: https://github.com/squillace/ralph-messed-up/tree/main/wit.
note there's no directory for wit/deps/clocks in this format, so I either have to munge the dir OR I can modify the paths in toml, right?
the following paths clearly should NOT work in this environment:
[package.metadata.component.dependencies]
"wasi:clocks" = { path = "wit/deps/clocks" }
"wasi:io" = { path = "wit/deps/io" }
"wasi:random" = { path = "wit/deps/random" }
"wasi:cli" = { path = "wit/deps/cli" }
so I go to munge the wit into something that looks like dan's:
no go
cargo component build version 0.15.0 and 0.14.0 do not locate the files so far as I can see.
so if this SHOULD work, and it should, then there's something wrong with my machine (entirely possible, detritus is a thing) and I'd like to figure that out.
cargo 1.80.0 (376290515 2024-07-16)
cargo-component-component 0.14.0 (wasi:95fee6f) or cargo-component-component 0.15.0 (which apparently has no commit in its version string)
wkg 0.4.1
what else? It sure seems that somehow the resolution pathing in cargo component's resolution is off, or I'm getting some version crossed.
https://github.com/squillace/ralph-messed-up/blob/main/Cargo.toml#L23
Should be...
[package.metadata.component.target.dependencies]
thanks @Brian ! That was it.cargo component
v0.15.0 creates [package.metadata.component.dependencies]
-- missing the infix target
rather, the cargo component new --lib
command with that version creates the older toml section name.
Taylor Thomas said:
Ralph Yeah this is still a work in progress. We are close to getting done with adding pulling from a registry: https://github.com/bytecodealliance/cargo-component/pull/322
There will still be some follow ups after that but we're getting there
@Taylor Thomas does this PR also fix the "cargo component new --lib` toml section name? Not critical if it doesn't; I'll file an issue if not.
No it doesn't fix that issue
Last updated: Nov 25 2024 at 19:03 UTC