-
Notifications
You must be signed in to change notification settings - Fork 261
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
Skip Scanning Index with Exact Version #228
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me -- I'm not sure what in particular was bothering you about the error message logic. I pointed out a couple minor style points but I didn't see anything really wrong!
I'll leave it up to you if you want to make any of the tiny changes I suggested.
version: version, | ||
from_url: from_url, | ||
error: error.to_string(), | ||
move |error| match error.downcast_ref::<HttpError>() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might separate the match
to a new line and brace the closure body:
move |error| {
match error.downcast_ref::<HttpError>() {
// ...
}
}
But otherwise this looks fine to me.
from_url: from_url, | ||
error: error.to_string(), | ||
move |error| match error.downcast_ref::<HttpError>() { | ||
Some(HttpError { code }) if *code == StatusCode::NotFound => DownloadError::NotFound { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is what was bothering you, it's fine. :) I'd probably prefer if
-let
but you can't concisely check the status code without the if-let-chains feature, which hasn't been implemented yet.
use reqwest::StatusCode; | ||
use std::fmt; | ||
|
||
// Once Issue #173 is implemented, we can use the ToolSpec struct to differentiate tools |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be nice to use a standard syntax for issue comments, esp for greppability. We've been using:
// ISSUE #173: Once it's implemented we can use the ToolSpec struct etc etc
Updated with the style changes. There wasn't anything specific bothering me about it, just mostly looking for a sanity check that there wasn't a simpler way that I was overlooking :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beauty :)
Updated the This caused a few other changes as other tests were failing, so also updated the exit code for a This has the upside of making |
@charlespierce This looks good. It's kind of a shame |
Closes #227
Prevent an unnecessary scan of the tool index (either Node or Yarn) by adding a
VersionSpec::Exact
type to represent a known exact version. Then when resolving the version we can shortcut and just return that version instead of doing a scan.Also updated the error messages in
distro
to handle the 404 response, which will most often occur when an exact version that doesn't exist is specified. Note: I'm especially interested in feedback on the approach taken to refactor the error messages, as I feel like there could be a more elegant way to approach the problem.