Beta testing rustup.rs

21

Initial reaction

I'll avoid reading any documentation, because real programmers know the docs always lie.

It will add the cargo, rustc, rustup and 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

:confused: 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. :stuck_out_tongue:

1 Like
22

This seems similar to the problems we have with the normal installers anyways: macOS packages and Windows MSIs are not signed Ā· Issue #27694 Ā· rust-lang/rust Ā· GitHub. Much seems to be "just"[*] acquiring a code certificate, keeping it safe and using it for signing.

[*] "just" because the process should be simple nowadays but I appreciate it isn't :(.

23

I find it a bit confusing that you should update a toolchain to install it.To me, update is something that happens after you have installed something, that is, update is stateful.

Using install for both first time installs and upgrades looks fine to me, because install sounds like a stateless command which will just overwrite existing version, if any.

And I don't see a problem in having two aliases, install and update, for a single command

5 Likes
24

rustup updates .bashrc and .zshrc, but I use .profile (OS X 10.11) :trollemoji:.

I did uninstall multirust first, but did get ā€œerror: multirustā€™s metadata is out of date. run multirust upgrade-data.ā€. Deleting ā€œ.multirustā€ helped.

25

Regarding ā€œshortcutsā€ I am not sure if they are worth ā€œbreakingā€ the consistency of the interface.

With a CLI, there are many options to:

  • recall the last commands
  • search a command among the history of commands entered
  • create a short-cut yourself (aka alias)

and of course, auto-completion of commands avoid a lot of typing to start with.

Regarding rustup toolchain, given that toolchain is a subcommand bag, I would expect it to list the available subcommands by default, much like I would expect rustup to just list the commands available. Though perhaps having to add a -h or --help flag afterward has some logic to it.

1 Like
26

I wonder if update still deletes previous version before downloading a new one and if it still starts downloading from the beginning after a failure?

Context: a week ago I decided to update nightly and because of bad internet (Iā€™m on vacation) it failed right in the middle of downloading docs. So I ended up without any rust installed and after I restarted update itā€™s started from beginning, given that the only thing left to download were docs. That was a bummer. I had to delete multirust-rs and download usual package, just to be sure that I wonā€™t have to wait for an hour more just to get another failure.

27

Hey Rustup is great. No issues for me. But could the script please also pull down the various etc folders so that I can symlink up to date shell completion? Not sure how others handle keeping this up to date

28

But how would this work provided that toolchain cargo directories are located somewhere inside ~/.multirust (and, I presume, inside ~/.rustup in the nearest future)? cargo install, for example, installs all binaries there. This is my main concern with rustup, actually - I think it is strange to use ~/.cargo for something which is not cargo. I also don't like how it is impossible to disable its .zshrc tweaking.

Other than that, I like rustup very much. I actually installed it from source manually several days ago instead of multirust, and it seems to be working great. multirust was a better name though :stuck_out_tongue:

29

Hi

This error message is a bit confusing:

$ rustup update nightly-16-03-03
 error: toolchain 'nightly-16-03-03' is not installed

The problem there is the naming format. The correct name is nightly-2016-03-03 (it took me a while to find that out) so I think a better error message would be something like error: toolchain 'nightly-16-03-03' does not exist.

30

I donā€™t want the script to touch my precious dotfiles. Iā€™d like the option to skip it.

Afterwards things seem to work OK so far. The docs say the files should land in ~/.rustup ($RUSTUP_DIR), but they seem to be placed in ~/.multirust instead.

2 Likes
31

Yes. It's for consistency with Cargo. There's a good argument that it's the wrong place, but they both need to change, not just rustup.

32

Good idea.

rustup installs to the same place cargo does. If this needs to be changed then cargo needs to change too.

Interesting. I'm not sure why that would be offhand (it prints "info: syncing channel updates for 'stable'" immediately for me) but I'll look into it.

You can switch to whatever toolchain you want with e.g. rustup default nightly-i686-pc-windows-gnu. (This is in the docs :p)

Just "stable". That is the name of the release channel. What sort of disambiguation are you expecting?

That's the second report. Thanks.

I'm not sure which is the best toolchain to select on windows. There are lots of possibilities. Right now it's i686-gnu and you can explicitly change to whatever you want. Somebody also suggested that rustup detect when it's run inside a Visual Studio cmd shell and base the toolchain on that.

multirust is deprecated and will be going away soon. You're right it might be helpful to explicitly state all the commands that will be installed, but I hoped that just explaining the location and that there would be other commands is enough (the existence of e.g. rust-lldb is not very crucial for newbies).

Sorry about this. rustup is in a transition. All multirust-ness will go away soon.

Thanks for the feedback. Issue.

Neat idea.

Hm. Nothing should have changed about this between multirust-rs and rustup. I'm guessing your error was Expected argument for flag '--features' but reached end of arguments. Issue.

This is also in the docs! Stable won't support components until 1.8. I don't intend to fix this in the UI because I'm just waiting for 1.8 to come out and fix it.

There's none yet. Issue.

Issue

Would you prefer then if rustup update did the everything-update?

Is 'install' a reasonable synonym for 'add'? rbenv uses 'install', so if we used that it would be familiar to rbenv users. Of course we already have 'add' for every other thing, so 'add' would be more internally consistent. We could also change all 'adds' to 'install' - toolchain install, override install, target install. override install is weird.

Great feedback. Thanks.

33

Does grouping commands into subcommands help?

Yes. Initially I expected rustup to behave a little bit more like nvm or rvm, but internally the consistency is good.

Do rustup and rustup update do the right thing?

I would expect a bare rustup to display helpful documentation, as if I'd run rustup --help, rustup update to update all the things, and rustup update <toolchain> to update a single thing.

Are the verbs right?

yup, seems good

What information is missing from the website?

Nothing - it worked like a charm for me (Windows 10 10.0.10586, 64-bit, MSVC 2015). I was easily able to install 32-bit, 64-bit, and 64-bit nightly.

34

I think it this environment variable should be documented pretty clearly somewhere rustup related. CARGO_HOME is clearly documented on crates.io, but it might not be obvious that rustup's behavior would be dictated by a cargo environment variable. This is important for me because I cannot use $HOME due to quota issues

1 Like
35

Thanks for the feedback. It should probably even be a command line option during install. Here's an issue.

36

Having setup as part of an executable's name just change how Windows treats that executable. My vague recommendation would be to not use setup in the name unless it follows the behavior patterns of a typical Windows setup program.

37

I should just rip the code for this out of cargo-script and crowbar it into cargo.

Host triple.

Based on needing to install the VC++ build tools and a VC runtime to use it, I'd say the *-gnu toolchain is probably the better default choice. I don't know how 64-bit for *-gnu is these days, though; I haven't tried it in forever.

Farewell to thee, Multirust, your ship has sailed to sea.

If it's a placeholder thing, then not mentioning is probably fine.

That does make me wonder; what's the intended replacement invocation syntax? Running Cargo/rustc via something called rustup seems slightly weird (though only slightly).

Sorry; turns out I was a little too aggressive in culling details. Yes, that's the one.

Personally, yes, I think so. In that case, I'm at least specifying a verb, so taking that and assuming defaults feels file. No, I don't count rustup as a verb because it's one of those uber commands that rolls a half dozen utilities together; it's basically just a disambiguating namespace. :stuck_out_tongue:

add feels fine on the basis that you're adding a toolchain to the set you're asking rustup to maintain. I agree that install would be a more precise verb, but as you say, you're already using add everywhere else. Given that I don't feel particularly strongly about install over add, I'd personally fall on the side of add for the aforementioned consistency.

"Your long, only somewhat coherent impotent ranting has proven to be of non-zero value! Go you!" :stuck_out_tongue:

38

Normally you just run them as cargo and rustc. The only time you invoke them with rustup is with rustup run nightly cargo.

39

It looks like rustup run <foo> now only works when <foo> is one of rustc or cargo. Iā€™ve been able to run multirust run nightly ./build-docs.sh with the old multirust when publishing new releases of rust-phf but that now fails:

$ rustup run nightly ./build_docs.sh
error: command failed: './build_docs.sh' (Io: No such file or directory (os error 2))
40

Installing on Windows 10, the console window appears to print an error after I type ā€œYā€ but disappears before I can see what it was.

1 Like