Initial reaction
I'll avoid reading any documentation, because real programmers know the docs always lie.
It will add the
cargo,rustc,rustupand other commands to Cargo's bin directory, located at:
C:\Users\drk\.cargo
That is not where this directory should go. This is something multirust-rs got right, so it's sad to see this regress. It should be installing to the Local directory.
After hitting Y, there's a bit of a delay before there's any indication that rustup is doing anything. It's just long enough to wonder if maybe it's hung and start thinking about aborting and trying again.
Also, one thing I'm a little concerned of up-front is that there's no choice for the host build. I still run i686-*-gnu for various reasons. I'm going to be thoroughly annoyed if I have to constantly override this. I'll slightly less annoyed if I have to constantly update a toolchain I'm not using.
stable installed - rustc 1.7.0 (a5d1e7a59 2016-02-29)
But I wanted nightly. And... which stable?
On finishing, I get a "This program might not have installed correctly" dialog.
Ok, what did I get...
C:\Users\drk>rustc -vV
rustc 1.7.0 (a5d1e7a59 2016-02-29)
binary: rustc
commit-hash: a5d1e7a59a2a3413c377b003075349f854304b5e
commit-date: 2016-02-29
host: i686-pc-windows-gnu
release: 1.7.0
Huh. Actually wasn't expecting that. To be clear, while I'd be annoyed, I'm a bit surprised this didn't install the 64-bit toolchain on 64-bit Windows.
Wait... why is multirust still on the PATH?
Oh! So this is one of those "other commands". Would be nice to have a complete list so I know what to expect.
Hang on, I wonder if my test runner script still works...
Ok, ok; everything other than stable failed. Fair enough. Can I install a toolchain directly?
... why hasn't the test finished? It's stuck on stable... oh son of a... it has to re-clone the index. *miserable sigh*
(10 minutes later). Well, at least Cargo didn't get stuck for an hour like last time I had to do this. Let's try installing 1.2.0.
I'm confused as to whether I'm supposed to use rustup or multirust. Also, multirust claims that it will upgrade the ~/.multirust directory. Is this just a facade, or is it actually multirust? Do they do the same thing? Is one a strict superset of the other (in terms of managing toolchains)?
Let's try rustup... the output of rustup update --help isn't tremendously enlightening. rustup update 1.2.0 seems to be doing what I want. Again, it'd be nice to have some explicit indication as to which toolchain it's downloading (in terms of host triple).
While we wait: you know what'd be nice? Adopting a py-style invocation for the proxies. cargo -1.2 test is so much nicer than multirust run 1.2.0 cargo test.
Ok, that sort of ran correctly. One of my tests failed because multirust wouldn't accept this invocation:
multirust run stable cargo build --verbose --no-default-features --features ""
I just checked, and this works in multirust-rs.
Something new; let's try installing x86_64-*-msvc support.
> rustup target list
error: toolchain 'stable' does not support components
Ooookay... so what's the target subcommand for? And why not? Can I install a secondary toolchain with a different target?
> rustup update stable.x86_64-pc-windows-msvc
error: toolchain 'stable.x86_64-pc-windows-msvc' is not installed
> rustup update stable-x86_64-pc-windows-msvc
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: downloading component 'rust'
So that works... it was also a blind guess on my part. I don't see any way to list what toolchains are available. Would be nice. Just make sure it runs...
... OK, now cargo has hung at 0% CPU for absolutely no reason on trying to update the registry. *sigh* Anyway. Runs fine after that.
Does grouping commands into subcommands help?
I think it's fine, but it would be good if the subcommands that need subcommands printed out help by default. Off the top of my head, it might be nice to have a tips command or something that just spells out really common tasks in one screen so people have an idea of where things are.
Do rustup and rustup update do the right thing?
I'm leery of commands that do long, very expensive things by default. My expectation is that because it's a host for many subcommands, rustup alone should just print usage information. Like how git by itself doesn't do anything.
Are the verbs right?
This is something that I got snagged on with multirust: I don't want to update a toolchain, I want to add one. Why is there no add command? Do I have to install it manually? Is there some other step I'm missing? I think a little redundancy here is OK.
One thing that I was a little iffy on: if targets are part of a toolchain, why is targets top-level, as opposed to being a further sub-command of toolchain? i.e. rustup toolchain target add. I'm not hugely concerned either way; just something that I wondered when looking at the usage information.
What information is missing from the website?
I think I answered that above. 