Is there a simple Julia upgrade command?

If you upgraded from Julia 1.5.0 you shouldn’t have to do anything. If you upgraded from Julia 1.4.X you can copy .julia/environments/v1.4 to .julia/environments/v1.5 (just two text files).

8 Likes

Oh wow. This is not a great recommendation for newbies :sweat_smile: I don’t think it should ever be necessary to delete .julia. At most, you might want to delete .julia/registries/General. Deleting .julia makes for a not-so-great user experience and I’ve seen it recommended a couple of times now.

:+1:

5 Likes

Deleting .julia has no effect whatsoever for me. Of course, YMMV. People employ all sorts of tricks, which occasionally backfire.

I have now developed a portable version of Julia, with a completely local depot and Julia installation tree. I have tested many times, each time deleting everything and rebuilding from scratch. Never had any problem.

1 Like

Julia looks up files at C:\Users\⟨username⟩\.julia.
It’s easiest to set up a startup.jl file and put it in .julia\config. E.g., to check if your favorite packages are installed on REPL start and install if they’re missing:

atreplinit() do repl
    @eval using Pkg
    let pkgs = ["BenchmarkTools", "Revise"] # put here all the packages you want to install
        for pkg in pkgs
            if Base.find_package(pkg) |> isnothing
                @eval Pkg.add($pkg)
            end
        end
    end
 end
1 Like

Thank you for your help! That worked like a charm on standalone and Atom/Juno!

I have one lingering issue from this upgrade to 1.5.1. And maybe this is the wrong thread, but how do tell Jupyter Notebooks that I removed version 1.4.2 and am now using 1.5.1. I am using the Notebooks environment from Anaconda3 (Navigator v 1.9.12), just fyi.

I did try typing using IJulia and then notebook() since this is what I had previously done.

Again, I am a relative newbie. And as always, thank you very much for your help!

Five minutes of efficiently doing exactly the right things translates to half an hour of googling and swearing, and reading the documentation of symlinks, and searching through the forum after half-remembered advice on package copying.

I sometimes postpone updating for weeks or months because of this. Doing something Julia update, is an incredible improvement.

I don’t know why. I use Julia on Linux all the time, I simply unzip the tar file and that’s it.

By the way, rebuilding the portable version amounts to double-clicking a script file.
Let me know if you’re interested. (That is, if your thing is Windows.)

You have to install to the correct folder, and figure out the symlinks, and fix the package stuff/toml-files. That doesn’t happen by itself by unzipping. I don’t understand.

???
This is what I do: Remove .julia and

1 Like

I’ve heard asdf recommended, and I used it today and it seemed pretty nice and easy. It’s a generic version manager with a Julia plugin (you just do asdf plugin add Julia once asdf is installed to add the Julia plugin). Then e.g. asdf install julia installs Julia 1.5.1, or asdf install julia 1.0 installs version 1.0. And asdf global julia 1.5.1 sets julia to point at Julia 1.5.1.

edit: I wrote a longer version of this answer at How to update Julia from command line? - Stack Overflow

I think some users might lose data unexpectedly by deleting ~/.julia. In particular

  • Any dev’d packages they are working on inside of ~/.julia/dev. This could be major work loss if they didn’t commit/push in a while.
  • Any startup config they have in ~/.julia/config/startup.jl

There might be other losses I’m unaware of. Just a note to suggest that maybe we exercise some caution before recommending new users blast ~/.julia.

8 Likes

True. However I think the best thing to do is to develop packages outside of the .julia folder.
Consider just the inconvenience of having to locate the source files.

I think a good practice would be to consider the entire .julia folder as read-only for the user. Remove any time. Storing stuff in this folder always seemed sketchy to me.

The loss of the configuration file could be painful, unless the users had the foresight to commit this file to a repo established for that purpose. That is how I do it, if a start up file is indicated.

By the way, I do use a startup file in the portable Julia installation. It is generated automatically, however.

1 Like

The portable Windows Julia installation is available here http://hogwarts.ucsd.edu/~pkrysl/shared/Portable_Julia.zip

Instructions: https://github.com/PetrKryslUCSD/dynamics-course-2020

It installs some packages you may not be interested in, but otherwise it is a fairly general
artifact. Feel free to tweak the installation script to suit your needs.

On Mac:

brew install julia

It’s true that if you use project files and manifests then your .julia should mostly be one big, complicated cache. Feels like blowing it away shouldn’t be necessary though—I never do. But it’s pretty excellent that reinstalling everything, even binary dependencies, is so reliable and quick that this is fine to do. Worth taking a moment to appreciate.

12 Likes

I’m sure this is all well and good. But it seems a lot more complicated and advanced than what you indicated at first.

Really? It is literally a single-line to make the installation happen (extract the tar file).
Then, for each package that I want to work on I clone it, activate it, instantiate it.

This discussion has happened many times before

Instead of deleting, it’s always been sufficient for me to transfer the environments folder to upgrade.

5 Likes

It might potentially be helpful for newcomers if the Windows installer could ask whether environments should be transferred from any existing Julia installs.

3 Likes