Skip to content

Conversation

@mkatychev
Copy link
Member

Summary

wkg wit build currently returns an unhelpful report when path resolution fails during resolve_dependencies:

$ wkg wit build --wit-dir ./wit --config wkg-config.toml
 INFO wasm_pkg_core::lock: dependency package was not in the lock file 
    package_ref=namespace:pkg1 registry=Some("my-registry.com") requirement==0.1.0
DEBUG wasm_pkg_core::resolver: dependency already exists and override is not set, ignoring
    name=namespace:pkg1
 INFO wasm_pkg_core::lock: dependency package was resolved by the lock file
    package_ref=namespace:pkg2 registry=Some("my-registry.com") requirement==0.1.0 resolved_version=0.1.0
DEBUG wasm_pkg_core::resolver: dependency already exists and override is not set, ignoring
    name=namespace:pkg2
Error: Unable to resolve dependencies

Caused by:
    No such file or directory (os error 2)

In the case above, pkg3 was the cause of the failure with logging failing to show it.

Changes

  • Added Display impl for Dependency
  • resolve_dependencies now attaches paths/dependencies to the relevant anyhow::Error:
    Caused by:
        0: namespace/pkg3
        1: No such file or directory (os error 2)
    
  • ran cargo clippy --fix
  • ran typos ./crates --write-changes

clippy

cleand up logging

typos ./crates --write-changes
@mkatychev mkatychev force-pushed the feat/display-dependency-impl branch from a8e8464 to f5126b1 Compare December 15, 2025 22:54
@mkatychev mkatychev requested review from lann and thomastaylor312 and removed request for lann December 18, 2025 18:39
Copy link
Collaborator

@lann lann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks good. Some style and error message suggestions.

return Some(reg);
}

self.fallback_namespace_registries.get(package.namespace())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a huge problem but the previous if/else if/else structure seems like more typical rust code.

Copy link
Member Author

@mkatychev mkatychev Jan 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can revert the style, I had a hard time understanding the else if let Some(_) chains because they all did things slightly differently and it made it tricky to reason about without a consistent corollary.

Only after I broke it down did I realize it was really the same lookup for two different fields.

Copy link
Member Author

@mkatychev mkatychev Jan 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For code golf's sake the function could be rewritten as this:

pub fn resolve_registry(&self, package: &PackageRef) -> Option<&Registry> {
    let namespace = package.namespace();
    // look in `self.package_registry_overrides `
    // then in `self.namespace_registries`
    self.package_registry_overrides
        .get(package)
        .or_else(|| self.namespace_registries.get(namespace))
        .map(|pkg| pkg.registry())
        .or(self.default_registry.as_ref())
        .or_else(|| self.fallback_namespace_registries.get(namespace))
}

EDIT: I went with a simpler (hopefully more rusty) approach.

@mkatychev mkatychev requested a review from lann January 7, 2026 15:51
Copy link
Collaborator

@lann lann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the updates

@lann lann merged commit 48c2882 into bytecodealliance:main Jan 7, 2026
3 checks passed
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

Successfully merging this pull request may close these issues.

2 participants