Rustup: `rustup default nightly` won't update the %PATH% if existing old install is present

Created on 26 Feb 2017 · 3Comments · Source: rust-lang/rustup

Hey guys, I have just solved an issue that's been plaguing me for a long time. It's a trivial one when one takes time to look into it, but it could be a gotcha that affects other people and makes them shy away from playing with Rust on Windows, which'd be extremely unfortunate.

I have had a super old install of Rust, pre-rustup lying around in my system. This caused issues, specifically, I wanted to try out Rocket so I went rustup install nightly-2017-02-25 (today's latest nightly won't work due to rust-lang/rust#40106) and then rustup default nightly-2017-02-25. However, running rustc --version gave me this: rustc 1.11.0 (9b21dcd6a 2016-08-15)

The reason for that is that where rustc returns C:\Program Files\Rust stable GNU 1.11\bin\rustc.exe and only then as a second value what it should, based on How rustup works: %USERPROFILE%/.cargo/bin/rustc.exe. I have simply deleted the first directory and that solve the issue of the old version of the compiler being picked up.

I think rustup should have a heuristic built in that after installing or defaulting a new version runs rustc --version and cargo --version and check that the returned versions match what they should. If there is a mismatch, it should print out where rustc and where cargo (which on Unix) and help the user figure out what was wrong, maybe even give them a tip on how to change %PATH% using command line - many Windows developers are not very familiar with command line, but that shouldn't prevent them from trying out Rust. I would rather rustup did not change %PATH% automatically, but it should tell the user where it detects and error and help them understand how to fix it.

What do you guys think? Practical? I don't know what's in the rustup manifests, but I am sure there is a way to surface the proper rustc and cargo versions so this check could be made. Thanks!

bug

Source