Why does juliaup delete the old versions?

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.

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.


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

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

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

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


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.


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

1 Like

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

@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.


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.

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

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.