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

Versioned dependencies (via --dep) are not found #136

Open
itowlson opened this issue Jul 29, 2024 · 3 comments
Open

Versioned dependencies (via --dep) are not found #136

itowlson opened this issue Jul 29, 2024 · 3 comments

Comments

@itowlson
Copy link
Contributor

I have the following WAC document:

package root:[email protected] targets fermyon:spin/[email protected];

let c = new root:component { ... };

export c...;

I resolve it like so:

wac resolve aaugh.wac --registry wa.dev --dep "root:component=./target/wasm32-wasi/release/calculator_spin.wasm"

And life is good. But if I change root:component to have a version:

package root:[email protected] targets fermyon:spin/[email protected];

let c = new root:[email protected] { ... };

export c...;

and invoke with the version:

wac resolve aaugh.wac --registry wa.dev --dep "root:[email protected]=./target/wasm32-wasi/release/calculator_spin.wasm"

I get:

error: failed to resolve document

  × package `root:component` does not exist in the registry
   ╭─[aaugh.wac:3:13]
 2 │ 
 3 │ let c = new root:[email protected] { ... };
   ·             ──────────┬─────────
   ·                       ╰── package `root:component` does not exist
 4 │ 
   ╰────

(If I revert the command line to the unversioned, uh, version, same error.)

Is this behaviour intentional? If so, could the error indicate more specifically what the user should do to fix it?

@calvinrp
Copy link
Collaborator

This might be the relevant line that needs to be revised: https://github.com/bytecodealliance/wac/blob/main/crates/wac-resolver/src/fs.rs#L37

Some(path) if key.version.is_none() => { might need to drop the conditional requirement that version not being specified in order to use the overrides file path.

@itowlson let me know if that fixes

@itowlson
Copy link
Contributor Author

@calvinrp Thanks for looking into that. The fix you suggest worked for me (in my one test case!). I haven't explored if it impacts anything else though - @peterhuene do you recall why you specified that condition?

@calvinrp
Copy link
Collaborator

A PR could add additional test cases and document the expected usage patterns. Seems safe to do.

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