I maintain my Julia installation from @staticfloat’s PPA, and I wish I could keep doing that.＊ However, it’s time for me to move on from version 0.5, which means I need to transition to the official binaries. How can I do this without creating version conflicts, or leaving obsolete junk files all over my system?
＊ Thank you, @staticfloat! Without the PPA, I might never have tried Julia.
Stability
Ideally, I’d like to make sure that I have at least one working Julia installation on my system at all times during the transition, because there’s no good time for my Julia code to be unavailable. I’d also like to be able to get back to my old system state if I really need to—for example, if I’m asked to run a program on short notice, and I discover that it no longer works under Julia 1.2.
Package files
Will the new package manager (introduced with Julia 1.0) respect the directory structure of ~/.julia set up by the old package manager, creating a v1.2 directory for the packages I install after the transition? If not, how do I transition to the new package manager?
Operating system integration
The newer Julia releases seem to live entirely in a single directory, but my installation has binaries scattered across many different directories, including
/usr/lib/x86_64-linux-gnu
/usr/bin
/usr/share
/usr/share/applications
/usr/share/lintian
/usr/share/doc
/usr/share/appdata
/usr/share/man
/usr/include
/usr/etc
/etc
Will Julia really still work the way I’m used to when all this stuff is gone?
It should be possible to install the official Julia binaries without interfering at all with your PPA-provided instlalation and without introducing any clutter. My process on linux is the following:
I download the official binaries from Download Julia and store them in a folder (I happen to use ~/apps, but you can put them anywhere you want). I keep each minor Julia version in a separate folder.
I then create a symlink in /usr/local/bin/ with the appropriate julia version. For example, I might do:
Having versioned symlinks means it’s easy to run different Julia versions, (e.g. running julia-1.2 or julia-0.7 as needed).
I then create one more symlink inside /usr/local/bin:
sudo ln -s julia-1.2 /usr/local/bin/julia
This means that when I run julia I get julia-1.2. I can then switch my “default” julia version just by changing that symlink.
And that’s it. Julia never needs to install anything system-wide, and all of the packages will live under separate folders inside ~/.julia, with separate folders for each minor version of Julia. None of the files installed by the PPA version of Julia will be necessary if you use the official binaries.
You also don’t need to do anything special to transition to the new package manager – it should just work and should not overwrite any of your packages from older Julia releases.
Unless you are maintaining a multi-user machine, just download and extract the tarball it wherever you like (eg I generally keep them in various directories like ~/src/julia-1.2), put it in the environment variable PATH, and you are done.
Some Linux users like to have a single directory for various scripts, eg ~/bin, and put that in PATH. In that case, just make a symlink to the Julia binary from there.
Generally it makes sense to keep multiple Julia binaries around, eg for testing on an earlier version, or trying out a pre-release, just name symlinks accordingly.
Oh my gosh, this is great! The day you posted your answer, I downloaded the official 0.5, 0.7, and 1.2 binaries into their own folders, as you suggested. I could call bin/julia from each folder to run whichever version I wanted, and the three versions ran smoothly side by side. I verified that my old code ran as expected in 0.5, and then used the deprecation warnings in 0.7 to port everything I was working on to 1.2.
Each version comes with its own independent Pkg environment, as you said. I only ran into one package management subtlety: I’m developing one project in a custom environment, and that environment seems to be shared across versions. As a result, I suspect the version of each package in the custom environment might depend on which version of Julia I was running when I last updated it. Since I’ve been moving from earlier to later versions, I can’t tell whether this is actually happening, or whether it could cause a problem if I moved backward.
Now that I’m confident everything works, I’m ready to remove the PPA version of Julia, and set up versioned symlinks like you described. Thank you so much for your help! I thought transitioning to the official binaries was going to be a nightmare, but it really was just as easy as downloading a single folder and putting it somewhere. I’m eager to clean up all the scattered binaries from the PPA version, now that I know I don’t need them.
Thanks for dropping by! I came across Jill while I was studying how to transition to the official binaries, but I didn’t try it, for two reasons.
I wasn’t sure how it might interact with the PPA version of Julia. How would it deal with the fact that I already had a julia executable in my system path? Would it respect the directory structure of ~/.julia set up by the old package manager?
I couldn’t easily figure out what it was doing. If the installation failed—and maybe even broke my existing PPA installation—I would have to trace through 150 lines of bash script (with 10 lines of explanatory comments) to figure out what I’d just done. I know Jill isn’t particularly complicated, but it has enough moving parts that I’d find them hard to keep track of, and I’m not fluent in bash.
Now that I know how easy it is to install the official binaries by hand (if I don’t need to have Julia in my system path, it’s literally just downloading a single folder and putting it somehwere!), I’m afraid I’m not eager to try Jill. When I’m working outside the Ubuntu package management system, I like to keep track of what I’m doing as well as I can, and in this case the easiest way to do that is by hand.