Feature Request: Add an auto-update mode

[nathanrboyer]

I'd like to see a juliaup command which would activate an auto-update mode, so casual users can set it and forget it (at least until Julia 2.0). This would check for a new version periodically, delete the outdated version #53, and link the julia command to the new version.

I am currently having coworkers install Chocolatey and the choco-upgrade-all-at package to achieve this, but it would be much nicer to have a Windows Store product for ease of finding and permissions.

It would be cool if the auto-update part could take advantage of #43 and startup.jl to update whenever a user starts Julia. If not, a cron-like shell script running once a day could also work.

[davidanthoff]

So I think we would first need https://github.com/JuliaLang/juliaup/issues/15. And then there are really two steps we need to take:

1. download new versions
2. swap versions out

For 1) we might need some sort of background download service, or use some of the APIs in Windows for that.

For 2) we would essentially have that code in the launcher/wrapper, it would presumably look quite similar to https://github.com/JuliaLang/juliaup/blob/6a813be4fe0d87fd80847b5d71e4ba9d4b4d1e05/launcher/main.cpp#L132.

[johnnychen94]

I'm not sure how Windows does this, in Linux people can just set cron jobs. For example, in jill.py we could do

# /etc/cron.d/jill
PATH=/usr/local/bin:/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin

* 0 * * * root jill install 1 --confirm --upstream Official
* 0 * * * root jill install latest --confirm --upstream Official

jill install 1 will be a no-op if there aren't new releases.

[davidanthoff]

With https://github.com/JuliaLang/juliaup/pull/190 almost done, this issue here is the one remaining major feature before we can really ship the Mac and Linux version.

We do have juliaup self update working, so the question now really is only how we can trigger that semi-automatically so that users don't have to explicitly ask for updates.

I broadly see two ways:

1. install a cron job that runs juliaup self update on some schedule
2. trigger a version check and potential update in some common code path that users run as part of using Julia

In general, 1) seems a more elegant solution, but I'm a bit worried because it means we depend on a "third party" piece of software that could be misconfigured, and then our stuff doesn't work. For example, is cron always installed on all Mac and Linux systems? What if a user changes some config around cron and then our update job no longer runs? What about uninstall? Is there a user-specific cron job, i.e. can we install a cron job without sudo? One problem here is that I'm very unfamiliar with all of this stuff :)

For 2), my idea would be that julialauncher checks at each start a field in the juliaup.json file named LastUpdateCheck, and if the current time is say 24h later than that, it normally spawns the julia process, and then immediately after that it also spawns juliaup self update -q as a detached process. And then juliaup self update updates the LastUpdateCheck whenever it runs in the config file. So in that scenario, running julia from an end-user perspective triggers auto-update, but hopefully the implementation is such that it wouldn't slow regular julia launches down.

One other consideration: I think 2) would not work with systemwide installs, we would probably really have to stick to user specific installs.

Input from @StefanKarpinski, @deoradh, @simeonschaub, @KristofferC or anyone else would be welcome!

[deoradh]

I checked on the question of cron on MacOS. It is supported, but launchd is preferred: https://www.launchd.info. I've not used the former in a couple decades, and have never used the latter. ;)

As for cron and how it interacts with sudo, this has an interesting suggestion: jobs can be set not to require a password. https://superuser.com/questions/1491793/how-to-create-cron-jobs-that-require-sudo-permissions

A system-wide install would I imagine be from the point of view of the user who would be granting the permission not to require a password for updating, so.. seems reasonable?

[simeonschaub]

Installing a new Cron job by default seems a bit aggressive to me for a relatively simple utility package like this. I think as a Linux user at least I'd prefer Juliaup not trying to be too smart for its own sake here since people's setups and workflows can vastly differ and on some setups you really want to have total manual control over which versions of software you are running and might not have permanent internet access. Messing with crontab could also potentially screw with existing services if Juliaup didn't detect how to call itself correctly which I'd imagine would make some Linux admins very angry... 😁

I think if we can, we should try to get Juliaup into distros' repositories and perhaps automate most of the release process like we do for the AUR on Arch. Then updates to Juliaup get installed alongside all other system updates. I understand our relatively fast development cycle might not be a good fit with the more conservative distros like Debian though.

If users install Juliaup using the install.julialang.org script, maybe we can have the juliaup update command do a self update by default as well? I don't think I like julialauncher looking for new versions on the internet automatically, but maybe it can print a warning if you haven't run juliaup update in a week or so? OTOH, that might just be annoying.

[davidanthoff]

I think if we can, we should try to get Juliaup into distros' repositories and perhaps automate most of the release process like we do for the AUR on Arch.

Yes, agreed, that really should be the long-term goal. BUT, I think it will be long term, and for some platforms (like Mac) there really isn't any such story, as far as I can tell, so we need to come up with some plan for those.

One of the primary scenarios I want to solve with juliaup is the "casual" Julia user (i.e. some of my students and many collaborators), who once follow some instructions on a web page to install Julia, use it a bit, don't touch it for six months, then come back and want to work with me on something. I want those folks to be nudged towards newer Julia versions, without me having to tell them :) So for that scenario, anything that would require them to run juliaup in any form just to get a message that they have an outdated system won't work because they won't even know what juliaup is. For that scenario I want to find some solution that works, even if the user only ever starts julia itself. So in my mind for this user group, a cron job (or something like it) seems the best solution.

I also hear @simeonschaub that just silently installing a random cron job that does something is probably not what another user group wants... So we'll need to find some solution that works for both user groups.

So far I've experimented with creating these cron jobs in https://github.com/JuliaLang/juliaup/pull/193. The model is that juliaup self install creates or updates the cron job, and juliaup self uninstall deletes it again. My general idea is that we move all install steps (including the shell startup script modification that is currently in the shell script) into those two commands for the self update scenario, and then shell script would then run self install as the last step. One idea would be that juliaup self install shows an initial prompt that is something like:

Do you want to install with the default options?

This would modify file X, Y to add `juliaup` and `julia` to your `PATH` and 
will also install a cron job to keep `juliaup` itself updated.

If you want to install with these default options, press X,
if you want to configure things individually press Y,
If you want to abort, press Z

or something like that. So the default nudge here would be towards "add to PATH and add cronjob", but users would be informed and could opt out. We could also add additional command line flags that also make these choices.

[nathanrboyer]

I think it would be better to keep the update method contained within Julia so that ...

1. juliaup doesn't leave remnants in important system files
2. juliaup doesn't have to support three different third-party update methods a. Windows - schtasks b. MacOS - launchd c. Linux - cron

What if you add juliaup self install to startup.jl instead of to cron?

[davidanthoff]

Here is my current plan: support both a background update job and the kind of "check for updates when Julia runs" option, have both configurable via juliaup config and then we can still figure out what we want the default to be. The "check for updates when Julia runs" option will be similar to adding it to startup.jl, but less resource intensive.

[davidanthoff]

So we now have auto update at intervals when julia is started (but in a way that should not slow down anything), plus optional cron job updates. I'm going to close this issue here and will open another one, I would still prefer to use launchd on Mac down the road. If folks want to try this, you can use curl -fsSL https://install.julialang.org/releasepreview | sh and then wait for me to push an update.

[davidanthoff]

Ah, wait, this issue is actually about something else, I completely lost track :) What we have now is auto-update of juliaup itself on Linux and Mac, but of course this issue here asks for an option to silently auto update a given channel. That will have to come later, but I'm reopening this issue.

[nathanrboyer]

Currently, if your version of Julia is outdated, a banner is printed in the REPL above the Julia logo on startup:

Julia version 1.7.3 is available. Run: juliaup update

#43 is still needed to show people how to update properly:

julia> juliaup update
ERROR: syntax: extra token "update" after end of expression

However, if juliaup is set to the release channel, why not just do this process automatically instead of printing the banner:

julia> ;
shell> juliaup update
shell> <-
julia> println("Julia needs to close to update to the latest version. Please try again."); sleep(5); exit()

It might also reopen the REPL in context if possible.