Why does juliaup delete the old versions?

General Usage
1

I started with this:

$ juliaup status
 Default  Channel  Version                     Update                                     
------------------------------------------------------------------------------------------
       *  rc       1.10.0-rc2+0.x64.linux.gnu  Update to 1.10.0+0.x64.linux.gnu available 
          release  1.9.4+0.x64.linux.gnu       Update to 1.10.0+0.x64.linux.gnu available

And ended with this:

 $ juliaup update
Installing Julia 1.10.0+0.x64.linux.gnu
$ juliaup status
 Default  Channel  Version                 Update 
--------------------------------------------------
       *  rc       1.10.0+0.x64.linux.gnu         
          release  1.10.0+0.x64.linux.gnu

I see it lists both as ready to be updated to 1.10.0, but assumed that was a bookkeeping entry and the older versions would still be available on my system.

In particular, it deleted my startup.jl files. In that case I can use ~/.julia/config/startup.jl, but in general I assumed the purpose of juliaup was to let me have multiple versions simultaneously installed on my system. Eg, in case I had code depending on a specific older version.

2

Well, the release version of Julia is now 1.10, so the release channel now holds that. If you want to use Julia 1.9, you can add the 1.9 channel: juliaup add 1.9, and then version 1.9 will stay around. Or you can also add a specific version, say juliaup add 1.9.2.

In particular, it deleted my startup.jl files.

That must have been something else, juliaup never does anything to that file.

10 Likes
3

It deletes the entire directory for the old version, including the startup.jl file.

Ie, when installing the new version it created a new (empty) startup file here

~/.julia/juliaup/julia-1.10.0+0.x64.linux.gnu/etc/julia$ ls
startup.jl

Apparently anything I place in that file will be deleted (by default, at least) if I update again.

4

Your startup.jl should better be in .julia\config\

EDIT: Sorry, you know it, just saw it in your OP.

2 Likes
5

Ah, also missed the details on the startup.jl in the original post :slight_smile:

@oheil is right, the startup.jl in the Julia specific folders is not the right place to add modifications, in general with Juliaup you should consider everything inside the ~/.julia/juliaup folder as managed by Juliaup and you should not modify anything there by hand. ~/.julia/config/startup.jl is the right place to put your own custom startup code into. If you want to do different things for different Julia versions you can just use a if VERSION block in the startup.jl.

14 Likes
6

Thanks, this is a helpful way to look at it.

1 Like
7

I’ve not been a huge fan of juliaup’s release channel since I realized this. If I remember correctly, the first time it updated me from one minor release to the next I suddenly loaded Julia to a blank slate install. I know it maybe isn’t exactly “best practice”, but I have a fair number of packages installed in the default environment that I like to have at the ready when loading up Julia for quick calculations. Since then I’ve made a habit of just having the 1.x channels installed.

1 Like
8

@mike.ingold yeah that is more of a Julia design choice to have separate projects for each Julia version. I think it would be quite reasonable for Julia itself to ask the user if they want to copy a previous Project.toml over when Julia starts and detects that there is no project for the current minor version yet.

5 Likes
9

It wouldn’t be the simplest thing to implement, but it would be nice if juliaup could attempt to migrate the default Project environment when upgrading the release install to a new blank install.

10

I think that kind of default project migration would be better implemented in Julia itself.

11

I put together a registered package EnvironmentMigrators.jl to assist with this issue a few years ago.

julia> using EnvironmentMigrators
[ Info: Thank you for using EnvironmentMigrators.jl. Please run `EnvironmentMigrators.wizard()` to begin.

julia> EnvironmentMigrators.wizard()
Use the arrow keys to move the cursor. Press enter to select.
Please select a shared environment to copy to /home/mkitti/.julia/environments/v1.10/Project.toml:

...

It could use some attention, but I just tested it and it still seems to work just fine. I would appreciate feedback.

In general, I do not recommend populating your default @#.# environment with anything but small utility packages (Revise.jl, BenchmarkTools.jl). I highly recommend using shared environments such as @mkitti instead.

6 Likes