Centralize where paths are discovered #915
Conversation
| .parent() | ||
| .ok_or_else(|| anyhow!("Could not determine parent."))? | ||
| .to_path_buf(); | ||
|
|
||
| let juliaupselfexec = juliaupselfexecfolder | ||
| .join(format!("juliaup{}", std::env::consts::EXE_SUFFIX)); |
There was a problem hiding this comment.
So I don't really understand why we are doing this, i.e. why we start with the path to the binary, then take the parent, and then reconstruct the path to the binary here. BUT, that is how the code was before, and I'm nervous about changing it... And this might have been related to deal with some symbolic links stuff that I don't fully understand?
There was a problem hiding this comment.
Honestly I struggle to see the point of it as well. The only scenario I can think of for the reason of that, is that in windows current_exe doesn't return (maybe it didn't in the past?) the .exe suffix.
Dealing with symbolic links should be handled by .canonicalize() now anyway.
|
Nice to have this alternative! first a minor comment: probably still having the logic to get the exec path in a separate function can be beneficial for maintainability. On another note, I am really uneasy about the I would also really know what you think about the proposal of just instead using |
|
Any news regarding this? or comments in #886? |
| pub fn remove_symlink(symlink_name: &String) -> Result<()> { | ||
| let symlink_path = get_bin_dir() | ||
| pub fn remove_symlink(symlink_name: &String, paths: &GlobalPaths) -> Result<()> { | ||
| let symlink_path = get_bin_dir(paths) |
There was a problem hiding this comment.
See comment (second half): #886 (comment)
In short: I don't get why the get_bin_dir uses an undocumented environment variable JULIAUP_BIN_DIR.
If we want to depend on current_exe() then that makes JULIAUP_BIN_DIR a potential source of headaches, since almost by definition, the path obtained by current_exe() is the actual JULIAUP_BIN_DIR (unless I am not seeing the use case for it)
If the JULIAUP_BIN_DIR was exclusively introduced (in #165 ) as a kitchen sink for various versions' symlinks then I guess it's not such a big deal. But I must admit I still find it confusing, especially since it is not documented and so it seems like a left over from a past approach?
Also, using the somewhat arbitrary~/.local/bin as a default might not be ideal, Ideally as default we should just use the juliaupselfexec also for symlinks no? and then if somebody wants them inside ~/.local/bin then he can use the JULIAUP_BIN_DIR instead.
But at that point I would also expect to have juliaup or default julia symlink inside JULIAUP_BIN_DIR, which fights with the authority of current_exe() we are using now.
Alterantive to #886.
@ghyatzo I started to look into it, and then got carried away ;) I think this should be correct, but I'm also a bit nervous as any error in any of this would really be bad... If you could take a careful look if this all looks right to you that would be amazing.
The general idea now is that
juliaupselfexecfolderis the folder where thejuliaupbinary is located andjuliaupselfexecis the path to thejuliaupbinary itself. And all paths should be canonical.There is one thing I don't fully understand, I'll leave a comment at that location.