On this point, maybe one way to do this would be for the rustup cargo proxy to automatically check for updates when a cargo command is run.
$ cargo check
Rustup notice: A toolchain update is available.
stable-x86_64-pc-windows-msvc 1.72.0 -> 1.76.0
Run `rustup update` to install.
Obviously make this an opt-in option that is prompted on a rustup install. And probably only run the check once a day.
It could even start a download in the background then show a message on the next cargo command after the download completes.
$ cargo check
Rustup notice: A toolchain update is available.
stable-x86_64-pc-windows-msvc 1.72.0 -> 1.76.0
Update packages will be downloaded in the background.
Run `rustup update -N` to complete the update.
<<cargo check output>>
# later that day
$ cargo run
Rustup notice: A toolchain update is downloaded and ready to install.
stable-x86_64-pc-windows-msvc 1.72.0 -> 1.76.0
Run `rustup update -N` to complete the update.
<<cargo run output>>
-N flag is short for --notice, meaning it only installs the update that the user was informed of in the most recent notice.
It could check for a new version asynchrously by spawning a background process and then report it the next time a rustup shim runs. Also rather than once a day, it could probably check once a week instead.
If it's a single https request, I don't see why it would slow down the process much. If it's that big of an issue, we could put a really short timeout or we could start the check before certain commands like cargo check or cargo build and report the results after cargo exits.
Given that stable has a predictable release cadence, rustup wouldn't even need to do any HTTP communication to determine if there's (almost certainly) an update available, it'd only need to determine the current date. It might even be able to rely on a cron job (or Windows equivalent) to update a flag in its state file.
Well, unless we change the release cadence, I suppose
(I wonder how disruptive it'd be if I set up a scheduled task to do rustup update stable every Saturday morning before I typically wake up…)
Doing the check concurrently to sniffed cargo compilation commands could work (although parsing args to sniff them isn't free, it's certainly much cheaper than an HTTP request). However, I'm pretty sure rustup uses execvp on unix (replace this process with a new one) so wouldn't be able to do anything after cargo without changing that.
The minor version bumps have predicable cadence. 2023 saw 7 point releases in addition to the 9 scheduled releases. I think once a week is better for that reason.
(And I don't think relying on having crontab permission is a good idea.[1])
Or on configuration outside your control more generally; maybe I restored my install from backup, maybe my install is on a shared drive... ↩︎
As a single data point: I'm frequently on old stables because I just don't think to check. If I check, and there's an update, it immediately downloads it which ties up rustup for a good 10-15 minutes, so I'm slightly disincentivized from checking.
Also, I'm lazy.
I think a periodic background check followed by a little "Note: update to $TOOLCHAIN is available" would be nice... so long as I can silence it if I need to.
I think it should be shown whenever build fails due to a "nightly" feature. Currently such errors have a vague suggestion to try another version, but a clear update info would be better.
I'm not sure about showing it for all commands though. It may be annoying to users who deliberately use an older version.
If you're explicitly using an old version you should be on e.g. the 1.32 channel, not the stable channel, which would only see when there are new patch versions on that channel.
How likely is it that the release cadence will slow down significantly? As a simpler version of this feature, something that warns you that rustup last checked for updates more than 8 weeks ago[1], and therefore that you're almost certainly missing updates would at least ensure that people are no more than one release behind accidentally[2], without needing a HTTP request during what "should" be an offline tool invocation.
Something like:
$ date '+%Y-%m-%d'
2024-02-27
$ cargo +1.34.2 build
Note: rustup last checked for updates on 2023-11-02.
Run `rustup update` to check for new versions
…
$ cargo +1.34.2 build
…
We could track time via the filesystem timestamp of .rustup, and have documentation tell you that we're doing this, so that you can stop the prompt ever appearing by running touch ~/.rustup or your OS's equivalent. ↩︎
Note that people who've chosen to stick to an old channel will still get prompted to run rustup update every 8 weeks in this proposal, even though they won't get changes this way - but we're at least reminding them that they're out of date. ↩︎
I recently used cargo install and my installed version of rustc was too old compared to one of the dependencies of the binary I was trying to install. So I had to manually run rustup update then re-ren the cargo install command.
Most softwares have automatic update nowadays (chrome, firefox, … and technically any web-based application like facebook, google maps, …). Since Rust tooling have an excellent backward-compatibility story, I think that they could be updated automatically, especially since there is an easy way to opt-out by selecting a specific toolchain and not "stable" with rustup.
If there are no update, running rustup update takes virtually no time. For cargo install is wouldn’t be an issue to update unconditionally. For cargo build we have to be careful to not increase the feedback loop.
Assuming you have network access and the servers aren't down, and your ISP isn't broken again (such that your computer thinks it has Internet access but really doesn't, that one happens regularly, 60 % packet loss ain't fun), ...
I'm not a fan of software that shouldn't need Internet hanging because they are trying to access Internet.
cargo install already requires internet access, so that's fine imho. For cargo build I totally aggree that a bad/no internet connection should not slow down the build at all.
Maybe the right balance is to try to do a rustup update whenever (and only when) we already try to access to internet while using the "stable" toochain?
rustup update definitely should not be run silently, without the user's prompt. Why should I be forced to download hundreds of megabytes of toolchain files, when I'm just trying to build my project? Normally I'd get at worst a few megabytes of source code downloaded, close to zero if all my crates are up to date. What if I'm on a metered connection? Or a spotty internet? Or just there is some other important network process running, which shouldn't have to fight over traffic with implicit rustup?
I can upgrade my toolchains on my own, thank you very much. Due to Rust's strict backwards compatibility, it usually doesn't matter that I don't upgrade for a few months (particularly if my dependencies don't bump MSRV), and missing a release by a few weeks is definitely a non-issue. There is no reasonable technical or social argument why Rust's users should be forced to constantly use the latest release.
