juliaup
juliaup copied to clipboard
using multiple DEPOT_PATH s with one julia installation
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.
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.
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.
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.
@jlapeyre I think your scenario can (almost) be achieved with the current implementation as follows:
- Create a depot that only contains the juliaup artifacts/config. I think
JULIA_DEPOT_PATH=~/foo julia
should do the trick. - And then you can run things with a clean depot for packages that pulls the juliaup artifacts/config from this
foo
depot by runningJULIA_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
.
+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.
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.
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.