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

support dependencies across multiple namespaces #91

Closed
wants to merge 6 commits into from

Conversation

macovedj
Copy link
Collaborator

@macovedj macovedj commented Apr 18, 2024

This leverages bytecodealliance/registry#263 from warg-client enabling wac to have dependencies across multiple registries/namespaces. The CLI now takes advantage of the namespace mappings that the warg client provides in its local storage.

Worth noting... if a user attempts to depend on a package that doesn't exist in the registry they're using, but does exist in another registry that their registry is aware of, it can provide a hint indicating that the user can update their namespace mappings to enable communication with the proper registry. This use case also required the addition of logic to retry many of the CLI commands after updating local namespace storage with the proper hint, preserving the same user experience that the warg CLI has.

I also figured it makes sense at this point to remove the feature flag that the registry support is behind, unless I missed some rationale for the flag. Figured I could easily add it back if there are any reasons not to.

@macovedj macovedj force-pushed the multi-namespace branch 5 times, most recently from 551e52a to ceb9671 Compare April 19, 2024 00:21
Copy link
Collaborator

@rylev rylev left a comment

Choose a reason for hiding this comment

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

Cool stuff! I think we should probably see the changes land in warg-client and related crates first before we consider merging this here.

crates/wac-resolver/Cargo.toml Outdated Show resolved Hide resolved
crates/wac-resolver/Cargo.toml Outdated Show resolved Hide resolved
crates/wac-resolver/src/lib.rs Outdated Show resolved Hide resolved
crates/wac-resolver/src/registry.rs Show resolved Hide resolved
crates/wac-resolver/src/registry.rs Outdated Show resolved Hide resolved
self.client
.get_warg_registry(id.namespace())
.await
.map_err(|e| CommandError::WargClient(e))?
Copy link
Collaborator

Choose a reason for hiding this comment

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

it would be nice if these errors were more context aware. Instead of just storing the warg error, we should add some additional context, let that this is fetching the registry.

crates/wac-resolver/src/registry.rs Outdated Show resolved Hide resolved
src/bin/wac.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@rylev rylev left a comment

Choose a reason for hiding this comment

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

Thanks! The biggest issue I can see with this change currently is that the changes to error handling seem to be more invasive than they need to be. It would be nice if we could slot the new error conditions into the existing Error enum - these errors are still errors in resolution, so I'm not sure why we can't just expand the current error handling.

@@ -38,7 +39,7 @@ tokio-util = "0.7.10"
tempdir = "0.3.7"

[features]
default = ["registry"]
default = []
Copy link
Collaborator

Choose a reason for hiding this comment

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

Unless it makes it harder to implement, I'd rather we leave the registry feature in in this PR. We can discuss it's removal either in an issue or in a PR specific to its removal.

use indexmap::IndexMap;
use miette::{Diagnostic, SourceSpan};
use wac_parser::Document;
use thiserror::Error;
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: elsewhere we're using thiserror::Error qualified instead of through a use. Can you replace Error everywhere with thiserror::Error?


#[derive(Debug, Error)]
/// Error for WAC commands
pub enum CommandError {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This doesn't seem right. Why weren't error variants just added to the Error enum?

Comment on lines -156 to -160
.map_err(|e: anyhow::Error| Error::PackageResolutionFailure {
name: key.name.to_string(),
span: *span,
source: e,
})?;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Removing this seems like a regression.

Comment on lines -169 to -173
.map_err(|e| Error::PackageResolutionFailure {
name: key.name.to_string(),
span: *span,
source: e,
})?
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same here - I'm not sure why this was removed.

.get_warg_registry(id.namespace())
.await
.map_err(|e| {
CommandError::WargClient(
Copy link
Collaborator

Choose a reason for hiding this comment

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

It seems like adding an Error::WargRegistryResolutionError (or similar) would be a better solution rather than having a CommandError type.

@@ -217,15 +225,20 @@ impl RegistryPackageResolver {
bar.finish();
}
}
Err(ClientError::PackageDoesNotExist { name }) => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same here - I'm not sure why it's an improvement to remove these errors.

@macovedj
Copy link
Collaborator Author

macovedj commented May 7, 2024

Closing in favor of Calvin's new PR, which incorporates new warg changes which should simplify quite a bit.

@macovedj macovedj closed this May 7, 2024
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.

3 participants