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 |
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.