Is there a simple Julia upgrade command?

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 https://stackoverflow.com/a/63694160/12486544

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

You lost me. I want to bring with me, say, 30 packages from the previous version. The process you describe here seems vastly more laborious than the manual procedure I already use. Not to mention the super simple update scripts in Jill.py.

And also, you have to fix the symlink stuff, which always takes me quite a bit of time.

I mean, why would I google each package individually to get their url and git clone them, instead of doing Pkg.add? Or just copy over the manifest/project files?

I’m just mystified because your response seems to be: “Why would you spend 2 seconds updating with Jill/chocolatey, when you could spend five minutes doing [complicated and confusing process]?”

3 Likes

I think you missed that (1) I cloned the package I wanted to develop (edit its files etc), and (2) I used project files to get all the packages that the developed package depends on.

I don’t know if by “30 packages from the previous version” you mean that they were used in your work, but if so, I “brought with me” all of that stuff with “activate .; instantiate”.

And what symlinks are you talking about?

1 Like

I was responding to this, and the various follow-ups:

This quote was, I belive, in reference to “how to upgrade Julia and packages”. When I said that surely this couldn’t be all there was to it, and how to upgrade packages and everything, you brought up the git clone business. As far as I can tell now, that referred to something completely different, not related to upgrading packages.

You must upgrade symlinks to be able to start Julia from the terminal with $ julia, and have a fixed path in your various editors etc.

1 Like

This assumes the editors used have the knowledge of julia, and that you will not have a dedicated terminal always open that you just hit backspace and start julia again when needed.

No, it doesn’t assume anything. If you want to start Julia with the julia command. If you use an editor that needs a path.

But I think it is safe to assume most users do this.

1 Like

Is there any technical barrier to writing a Julia updater in the form of a package?

1 Like

That is my “portable Julia”. Run any Julia version, in its own private sandbox. :wink:
All paths set up automatically, editor preconfigured.

1 Like

However I think the best thing to do is to develop packages outside of the .julia folder.

+1 on this. Just have to remember to pass in the correct path if you use PkgTemplates, for example. I too am a Windows user and have had to obliterate my .julia folder on several occasions. Each time it fixed the problem that led me to do it and didn’t cause new ones :smile:

3 Likes

Not if you already have julia on your system!

does just that. To answer the OP’s question,

]add UpdateJulia
using UpdateJulia
update_julia()
5 Likes

There’s a JULIA_PKG_DEVDIR environment variable that you can set to where you want to develop packages with the Pkg dev command. I have that always set to my ~/dev directory.

4 Likes