Thursday, 14 February 2019

Updating Rust Nightly

So Rust has a pretty usable nightly build. Actually it has an extremely usable nightly build that also keeps a huge set of powerful features siloed off from the stable branch (behind feature gates so you can turn on just the stuff you want to play with rather than being dumped into a thousand things that have been deemed to not actually be ready for prime-time yet). That attracts a lot of users to keep on nightly rather than stable (or the beta that is one update ahead of stable but also lacks nightly's features and so is the mid-ground no one uses unless they really believe in helping test the next stable for the public good). However, nightly isn't perfect(ly stable) and right now is a great example of where the update tools feel like they come up short vs the usability that is visible everywhere else for the Rust language ecosystem.

>rustup update

"error: some components unavailable for download: 'clippy', 'rls', 'rustfmt'".

As primarily a user of VSCode for Rust (also sometimes a JetBrains IDE, although the Community Edition plugin lacks any debugging feature so I'll revert to VSCode to debug) then the RLS isn't really optional. It is good that the updater tells me after finding that some of the components I have installed in the toolchain I asked to update are missing from last night's build. However, it does not then go on to give me any information about how I can get from however old my last installed version was to the last good nightly build.

As best I can work out, I have to browse to a site tracking the nightly builds by component and then tell rustup to update to the date last shown to have built correctly. But that's not actually the end of this story (which would be a bit of lack of useful info but not totally weird to not get that added info directly on the command line).

The behaviour of rustup update <dated nightly version> is not to update the nightly toolchain install already on your system but to install a second toolchain (the help does make it clear that you are effectively just running rustup toolchain install when you provide a toolchain argument). So now I've got a second toolchain installed with the last dated good build I took from that tracking site, except it's a default install so those optional components that I needed and weren't available in last night's nightly? Those didn't automatically get added to my new toolchain install (and for my use, they are not optional - if I could live without them then I could just force the update and it would wipe over the old stuff with the partially working current nightly). So now I have to go through the process of requesting those components be added.

None of this is the end of the world. Many other toolchain ecosystems are no better (and some are worse) when it comes to updating. But there is clearly room for improvement here and this is one of those pain points where a new Rust dev who is not used to any of this may not even really understand what's going on (after someone told them nightly was totally fine and just install that). Either they can't update or, worse, they end up with a VSCode IDE that has no RLS (and no way to get a corresponding RLS as that part of the nightly build is broken right now) which means it's not behaving like they expect it to.

A typical dev who is asking to update their nightly build probably wants to get the latest nightly that has all the components working that they have installed. That seems like a safe default to assume, maybe with a Y/N prompt after the error message rather than silently updating (if we are to be cautious). Leaving them with a potentially weeks or months old nightly (where they're potentially behind stable - not that hard for sporadic Rust users with the 6 week cadence of new stable versions and reasons to prefer nightly) because last night's build didn't work (and no easy way to update without just starting to install a totally new toolchain from scratch) does not seem like a suitable behaviour.

No comments:

Post a Comment