Use JULIAUP_DEPOT_PATH instead of JULIA_DEPOT_PATH

[davidanthoff]

This is an alternative to #596. The main differences is that there is a little less code changed, the default stays ~/.julia/juliaup and the tests now set both JULIA_DEPOT_PATH and JULIAUP_DEPOT_PATH.

[davidanthoff]

Quick update on this: I've changed this over to JULIAUP_DEPOT_PATH now (instead of JULIAUP_HOME). I really couldn't make up my mind which of these is better, but then I realized that in the existing standalone installer we actually refer to the place where the juliaup and julialauncher binaries go as "Juliaup home directory". So to me that decides it: we already use the term "home" for something else, so then it makes more sense to just have the config here be "the Julia depot into which you want the Juliaup config to go".

This does mean that the internal functions in Juliaup are misnamed, because there we refer to ~/.julia/juliaup as "juliaup_home", but we can refactor that down the road as that is not user-facing.

I'll probably merge this soonish, unless I hear objections :)

[DilumAluthge]

It would be great if we could get a review from @KristofferC before merging.

[davidanthoff]

Also pinging all the folks that I know chimed in on JULIA_DEPOT_PATH at various points. Does this PR look good to you? This is a breaking change and we went back-and-forth on this before, so I want to make one final change and then never touch this again, so your opinion whether this would work for you would be most welcome :) Sorry for the noise, also ;)

Essentially what it does is entirely remove the dependence on JULIA_DEPOT_PATH, and instead have a separate JULIAUP_DEPOT_PATH environment variable.

@KristofferC, @jakobnissen, @MichaelHatherly, @maleadt, @johnnychen94, @StefanKarpinski, @jlapeyre, @bjarthur.

[mortenpi]

If I understand correctly, the JULIAUP_DEPOT_PATH points to a Julia depot, rather than the juliaup directory? And so the actual directory where the binaries get installed will be $JULIAUP_DEPOT_PATH/juliaup?

Is there a specific reason to insist that the user should (semantically) specify a Julia depot, rather than just a directory? Like, let's say I want to have a ~/.juliaup directory. I can set JULIAUP_DEPOT_PATH=$HOME/.juliaup, but the binaries end up in $HOME/.juliaup/juliaup, which seems like unnecessary nesting? The default could simply explicitly be ~/.julia/juliaup, and it wouldn't actually care whether ~/.julia is a Julia depot or not?

That said, this is definitely a bikeshed, and the nesting doesn't really matter. And this change is awesome! I have also been bitten by juliaup's use of JULIA_DEPOT_PATH in the past.

[LilithHafner]

I prefer this approach over storing juliaup stuff in ~/.juliaup. IMO, nuking ~/.julia should delete as much as possible.

I also agree with @mortenpi that JULIAUP_DEPOT_PATH should be the path to where juliaup stuff is (defaulting to ~/.julia/juliaup), not the path to a "julia depot", defaulting to ~/.julia. That way, it is possible to set JULIAUP_DEPOT_PATH to ~/.juliaup and get

~
    .juliaup
        random
        stuff
        content

rather than

~
    .juliaup
        juliaup
            random
            stuff
            content

[lassepe]

May I carefully bump this PR?

[KristofferC]

The default could simply explicitly be ~/.julia/juliaup, and it wouldn't actually care whether ~/.julia is a Julia depot or not?

+1 for this.

Other than that, I still think the original proposal of having a separate .juliaup in ~ is better. Just because I remove my julia configs in .julia doesn't mean I want to remove my julia installation. In most software I use I can delete the config folder without deleting the program itself.

However, that is a small detail compared to fixing the current problem with JULIA_DEPOT_PATH so I won't push on that.

[IanButterworth]

@davidanthoff bump. Is there anything holding this up?

[IanButterworth]

@davidanthoff perhaps I could go ahead and merge & release this at the end of this week if I don't hear otherwise?

[davidanthoff]

I am pushing out a build right now with some smaller bug fixes and a new bundled Julia version. Once that is out for a few days without a sign of a regression I will merge this and then put out a prerelease build for folks to test.

[BoostCookie]

I know I'm late to the party, but shouldn't we adhere to the XDG Base Directory Specification (also see this ArchWiki entry) and use
${XDG_DATA_HOME:-$HOME/.local/share}/julia/juliaup
or
${$XDG_DATA_HOME:-$HOME/.local/share}/juliaup
as default? Now juliaup has become one of those pesky programs that need yet another environment variable to not clutter my $HOME.

[davidanthoff]

This is a different issue :) JULIAUP_DEPOT_PATH now controls in which Julia depot actual Julia versions are stored, including config etc. By default that is ~/.julia.

The location where Juliaup itself is stored is not affected by this PR at all. Those locations differ already quite a bit depending on how Juliaup is installed. Probably best to open a new issue for new proposals on that front.

[StefanKarpinski]

If someone wants to implement opt-in XDG support, it's been an open issue for a long time, has buy in from devs, but no one has actually implemented anything (despite many people apparently being interested). Our general stance is that Julia uses ~/.julia for everything by default on all platforms but it would be great to have an easy way to opt into XDG compliance. If that were to exist for Julia itself then it would make sense to follow the same opt-in configuration for juliaup but it doesn't make sense for juliaup to have a different way to opt in, so someone should implement XDG for Julia first and then juliaup can piggyback on that support as well.

[BoostCookie]

OK, but I still don't get what was wrong with juliaup using $JULIA_DEPOT_PATH.

[DilumAluthge]

See e.g. #596 for more context as to why using JULIA_DEPOT_PATH was a bad idea.