using multiple DEPOT_PATH s with one julia installation

[jlapeyre]

You might have julialauncher look in the default depot path as a fallback in case DEPOT_PATH[1] has no juliaup directory.

I'd like to use various main depots (the first entry in DEPOT_PATH) without running juliaup each time to install julia in the depot.

More precisely, I'd like to use juliaup to install to ~/.julia and then later this same julia with various other depots. But, ~/.juliaup/bin/julia, which links to the launcher of course can't find julia.

I am working on a project that manages a depot, etc. with scripts. If ~/.juliaup/bin/julia is the first on my system path, then the real julia binary will not be found. I imagine that other scenarios like this might arise in the future.

[davidanthoff]

So the idea would simply be we search through all the paths in DEPOT_PATH, until we find one where with a juliaup install, right? That sounds like a good idea to me.

[jlapeyre]

That's not what I had in mind, but it sounds like a good idea as well. I don't have a good grasp on different practical workflows that involve manipulating DEPOT_PATH. Checking a few scenarios: If I do "export JULIA_DEPOT_PATH=~/newdepot:", then this depot is prepended the usual contents of DEPOT_PATH. If ~/newdepot is empty, then the current behavior is ~/.juliaup/bin/julia begins to download a julia installation. If I interrupt this, and start julia again. Then julialauncher sees ~/newdepot/juliaup with no config file in it and says: "The Julia launcher failed to figure out ...". In this case, searching through DEPOT_PATH would have found the juliaup installs. So, it's useful if people do this.

(Here is the the doc for DEPOT_PATH and for JULIA_DEPOT_PATH.)

But, I am doing something different. What I am trying to do is replace the first entry in DEPOT_PATH, because I want to force new packages to be installed there (I have a reason that I omit for brevity). If I leave ~/.julia in DEPOT_PATH, then packages will be found there. I wouldn't be surprised if there are other use cases for this.

If you want to support julialauncher working in this case, then you'd want to search in the default depot even if it's not in DEPOT_PATH. The file initdefs.jl has exactly this: joinpath(homedir(), ".julia")

I have a library that looks for julia installations, juliaup, jill, the user's PATH, etc. It takes the version that best matches a spec. For now, I simply remove ~/.juliaup/bin/julia if it appears (eg on the user's PATH). The juliaup installs will usually be found anyway. So for my immediate use case, I am able to work around the issue.... There was another problem due to the symlink to the launcher encountered when scripting. If I can recall, I can open an issue.

[KristofferC]

In my opinion, DEPOT_PATH should be completely separate from how juliaup stores and searches for julia executables. juliaup is a manager of Julia installs so it sits "one level higher" up on the abstraction change. Therefore, settings made to influence Julia's behaviour should not affect juliaup because it means that you are tying julia's behavior to how it is installed. DEPOT_PATH has a documented behavior and I would say juliaup is not "allowed" to piggy back on it.

Someone setting DEPOT_PATH=/tmp/new_depot do not want to reinstall their julia, they want their existing Julia to behave the way it is documented.

Just to take an example from some other language. Cargo has the CARGO_HOME env variable which is a bit similar to DEPOT_PATH. Do you have to reinstall rust if you change that? I haven't tried but I am quite certain the answer is no.

So to me, store things by default .juliaup/releases (or some other subdirectory, rust apparently uses .rustup/toolchains) have a separate env variable JULIAUP_PATH or JULIAUP_HOME to set this and let DEPOT_PATH do what it is intended to do without surprising side effects would be the best way forward from my p.o.v.

[davidanthoff]

@jlapeyre I think your scenario can (almost) be achieved with the current implementation as follows:

1. Create a depot that only contains the juliaup artifacts/config. I think JULIA_DEPOT_PATH=~/foo julia should do the trick.
2. And then you can run things with a clean depot for packages that pulls the juliaup artifacts/config from this foo depot by running JULIA_DEPOT_PATH=~/bar:~/foo julia.

Something like JULIA_DEPOT_PATH=:~/foo julia would also work, if you want to use the Juliaup artifacts/config from the foo depot with your default ~/.julia depot for packages.

The one thing that one can't do with this setup is use a Juliaup artifacts/config location that is part of a depot that also has packages installed, and have Juliaup use that depot but regular Julia ignore it. Essentially if you add the depot to JULIA_DEPOT_PATH then it is visible to both Juliaup and Julia. A simple way to address that would be to add an env variable JULIAUP_DEPOT_PATH, that if set is used by Juliaup instead of JULIA_DEPOT_PATH.

[bjarthur]

+1 for @KristofferC 's suggestion to not put juliaup artifacts anywhere in DEPOT_PATH. like the OP, i am also trying to manipulate the DEPOT_PATH. a clean separation between juliaup and julia would solve the problem best.

[ulysses4ever]

I can't use juilaup because it insists on installing a fresh Julia (of a version not the one I need) when I pass a fresh depot, which I also, like others above, have to do a lot. Please do as suggested above: separate juliaup from Julia.

[kpamnany]

Also +1 to Kristoffer's comment.

Edit: with #510, I can make this work for me, but still think decoupling julia and juliaup environment variables is a better choice.