-
Notifications
You must be signed in to change notification settings - Fork 216
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
Check volta shims for reachability during tool install #1292
base: main
Are you sure you want to change the base?
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.
Thanks for this @untitaker, and apologies for the delay in reviewing! I've unfortunately been increasingly busy with my day job and haven't had the time to dedicate to keeping up with reviews.
Left a couple of suggestions for code organization, but the overall approach is sound and I think will be a big help 🎉
crates/volta-core/src/shim.rs
Outdated
@@ -89,6 +89,23 @@ pub fn create(shim_name: &str) -> Fallible<ShimResult> { | |||
} | |||
} | |||
|
|||
pub fn check_reachable(shim_name: &str) -> Fallible<()> { |
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.
Rather than make the public method fallible (and need to create a new error type), since this is intended to be purely informational, can we make this infallible and only show a message if we're able to successfully determine both the shim and the resolved and compare them?
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.
Separately, also a slight preference for moving this into the tool/mod.rs
file, rather than holding it here in shim.rs
. The main reason for that is we can then use the tool
helper functions for writing the message out (e.g. note_prefix()
and similar that are used for other notes).
Alternatively, we could have this method be something like is_shadowed(shim_name: &str) -> ShadowStatus {}
with an enum:
pub enum ShadowStatus {
NotShadowed,
Shadowed {
expected: PathBuf,
found: PathBuf,
}
}
And then only build the message inside of the tool
module.
crates/volta-core/src/shim.rs
Outdated
) | ||
})?; | ||
if resolved != shim { | ||
warn!("{} is shadowed by another binary of the same name at {}. Please ensure that {} is at the front of your PATH.", shim_name, resolved.display(), shim.display()); |
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.
Given where this is used, rather than warn!
, I would lean a little towards using info!
and note_prefix
, as that's the approach we've taken for a similar message when you install a global version of Node but the local version is different. In both cases, the message exists to let you know that while you just installed something, what you get when you run the command may not be what you expect.
crates/volta-core/src/error/kind.rs
Outdated
@@ -429,6 +429,11 @@ pub enum ErrorKind { | |||
name: String, | |||
}, | |||
|
|||
/// Thrown when Volta is unable to find the shimmed command. | |||
ShimResolveError { |
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.
As mentioned below, if we make the lookup infallible by handling (i.e. ignoring) the error directly, we shouldn't need a new error type.
tests/acceptance/support/sandbox.rs
Outdated
/// Add an arbitrary file to the test project within the sandbox, | ||
/// give it executable permissions, | ||
/// and add its directory to the *front* of PATH, shadowing any volta binaries. |
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.
nit: Can we update this doc comment to more accurately reflect what the method does? It appears that it doesn't work with any files, rather it only does the prepending. Can we also document the constraint that prepend_exec_dir_to_path
is exclusive of add_exec_dir_to_path
?
I think this also fixes #1053. |
@charlespierce i think i addressed all comments. initially i thought it would make sense to make volta hard-crash with exitcode 1 if the PATH can't be resolved to the shim (i think that would be useful when volta is used in CI), but when going back to this code i saw that only some error conditions were treated as fatal. |
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.
Thanks for continuing to iterate on this! A couple of small suggested tweaks to the language, to make sure that we are providing the best UX that we can in these situations.
There also appears to be a merge conflict with dependency updates.
crates/volta-core/src/tool/mod.rs
Outdated
Ok(resolved) => resolved, | ||
Err(_) => { | ||
info!( | ||
"{} cannot find command {}. Please ensure that {} is at the front of your PATH.", |
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.
Apologies for multiple rounds of iteration, but for an error / info message, we try to take special care to be as helpful as possible. Three relatively minor things that jump out here:
- Would it make sense to use the
home.shim_dir()
value for the CTA part? Using the shim path itself would mean that we would suggest putting~/.volta/bin/node
on thePATH
, when what we're actually suggesting is having~/.volta/bin
on thePATH
- Since Volta works on Windows as well (and we do these same checks), we should match Windows' casing for
Path
on those systems. So we should havePATH
on Unix andPath
on Windows. - Also related to Windows, with how the Environment variables are handled, I'm not sure "at the front of your Path" makes the most sense. For this case (the command couldn't be found at all), we can probably say something like "Please ensure that {} is available on your Path".
crates/volta-core/src/tool/mod.rs
Outdated
} | ||
}; | ||
if resolved != shim { | ||
info!("{} {} is shadowed by another binary of the same name at {}. Please ensure that {} is at the front of your PATH.", note_prefix(), shim_name, resolved.display(), shim.display()); |
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.
Similar comments as above for this message re shim_dir
and PATH
/Path
. I also wonder if it would make sense to expand the CTA somewhat, to make it clear why we're suggesting it? Perhaps something like:
To ensure your commands work as expected, please move {} to the start of your PATH.
@charlespierce I think I fixed both comments |
@charlespierce could you take a look? |
Sorry about the delay here, @untitaker – will see if we can get this reviewed and merged here shortly (at the start of the new year, if nothing else)! |
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.
LGTM! 🎉
I'll merge in |
Ah, I messed up the merge commit; I will re-create it and force push the correct version in a bit! |
67ce551
to
1679c39
Compare
Using `#[cfg(...)]` attributes on expressions is unstable, so switch to defining a constant with the relevant value behind a `cfg_if!()`, as we do elsewhere.
I can try to fix the test |
@untitaker that would be great! I fixed up the one build issue I saw, so you should be unblocked. Let us know when it's fixed and we'll get this merged. Thanks again, and thanks for your patience! |
Running this locally:
gives me this output for most tests:
|
@chriskrycho can you or somebody else help me figure out what is broken with my devenv? I can't figure out the broken tests before that. I am following the instructions in CONTRIBUTING |
Huh. That should have been fixed by some of the work @rwjblue and I did a little while back, but it's possible that we missed something there or that I did the merge above wrong or that we caused a regression. The issue is that the test mock is asking for a path named |
darwin-arm64 does make sense to me, that's just any new MacBook. So I suppose the devenv does not work on any M1 or M2 macbook? Not sure I switched to an x86 laptop for this PR, and everything worked out. Fixed the remaining test failure, so I think this PR should be ready to merge. |
Fix #1268