Closed ghyatzo closed 1 month ago
An Issue I encounter with that approach is that the juliaupselfbin
which would be the parent
folder to get_juliaup_path()
, is locked behind the selfupdate
feature, and so, not available in all places where access to the self path is required (i.e.: in the install_version
function in the operations.rs
file).
Another issue is that that would require passing the GlobalPaths
object to many functions that as of now do not require it and would need to get their signature updated:
install_background_selfupdate(interval: i64)
get_bin_dir()
do_initial_setup(juliaupconfig_path: &Path)
run_versiondb_update( config_file: &juliaup::config_file::JuliaupReadonlyConfigFile, )
run_selfupdate(config_file: &juliaup::config_file::JuliaupReadonlyConfigFile)
are all functions that would need to change signature for them to use the GlobalPaths
object.
Now that I dig a bit more in depth, I noticed also some inconsistencies on how the program refers to its own bin folder:
there is in use the functionget_bin_dir()
(from #165) for some symlink operations, which searches an env variable JULIAUP_BIN_DIR
or defaults to the parent of the binary if and only if the bin dir is within the user home folder.
But in the GlobalPaths
object we refer to the bin folder only as the parent of the executable (it was also like that before my changes).
It would very much be convenient to standardise this, so that there is only one "authority" that tells us which is the bin folder. From my point of view there are three possibilities:
current_exe()
) decide where is the bin folder, but that would conflict with existing JULIAUP_BIN_DIR
and therefore would require either rethinking that pull request. Moreover, now that JULIAUP_DEPOT_PATH
is a thing, we would have that juliaupselfhome != juliauphome
which I have trouble imagining a scenario where that could be beneficial.JULIAUP_BIN_DIR
or a default location) decide where to find the executable. This in my opinion would instead create some possible conflicts with the JULIAUP_DEPOT_PATH
which would need to remain in sync ot it might create inconsistencies.JULIAUP_DEPOT_PATH
(or a default path if it isn't set) be the only authority where we can find the bin dir and therefore the binary. This means getting rid of both JULIAUP_BIN_DIR
and current_exe()
calls.Personally I think that the most robust option is using JULIAUP_DEPOT_PATH
as the only authority if juliaup get's installed in a non default location. It makes little sense to have both JULIAUP_DEPOT_PATH
and JULIAUP_BIN_DIR
, and at that point we could also get rid of all current_exe()
calls.
then
juliaupselfhome = $JULIAUP_DEPOT_PATH
juliaupselfbin = juliaupselfhome\bin
my_own_path = juliaupselfbin\juliaup
But it could be breaking for some (probably only those using JULIAUP_BIN_DIR
, which isn't even documented).
Unless I am missing something foundamental, I don't really see why we should ever have juliauphome != juliaupselfhome
(which would require keeping the reference to the current_exe
)
@davidanthoff bump? any news regarding my comment above and/or your version in #915 ? Shall I close this?
Refer to #915
Fixes #885,
It centralises the resolution of the self path into a single function. Consolidated all the locations which queried the self path to call that function for better maintainability and consistency.
this change could also help towards #844, giving better support to symlinks and therefore custom locations