Beta testing rustup.rs

[brson]

@sfackler

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:

@sfackler Great catch. Thanks. Issue.

@sfackler

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.

Issue.

@hroi

You appear to be setting environment variables ("PATH") in your .bashrc or .zshrc: those files are only read by interactive shells, so you should instead set environment variables in startup files like .profile, .bash_profile or .zshenv. Refer to your shell’s man page for more info. Customize ‘exec-path-from-shell-arguments’ to remove "-i" when done, or disable ‘exec-path-from-shell-check-startup-files’ to disable this message.

Hm. @Diggsey had multirust-rs installing path modifications to ~/.profile and I changed it because ~/.profile is only read for login shells, and that seemed wrong since most shells are not login shells. I'm happy to change this to do the right thing, but I'd like to understand better why it's ok not to set the PATH for non-login shells. Issue.

@skade

While it fixes the "i need the compiler to run for ages until I have all my stdlibs"-problem, it doesn't solve the "cross-compile out of the box" problem

There's more work to come next quarter on installing the native toolchain components. We'll probably start with the android NDK.

@eminence

Forgive the tangent here, but in my opinion, the "cross-compiling" to x86_64-unknown-linux-musl in multirust is really really good. I'm not sure how it could be easier.

Yay!

@eminence

I like the simplicity of this mode of operation, but it doesn't feel like it's the exact right thing to do. I think my preference would be to have a bare "rustup" just print usage (just like multirust, cargo, and rustc). I don't upgrade toolchains often enough for me to get the benefit of not having to type a few extra keystrokes.

I've heard this feedback from others too. I intend to make rustup just print help, and move the update-everything feature to rustup update.

@eminence

In this message I wonder if you can print the previous version I had, so I can revert if necessary.

Good idea. Issue.

@m4b

I think I'd like rustup show to output hash and version of rustc, if that makes sense, and currently installed targets, or add a show to targets rustup target show.

I think this makes sense too. Here's an issue. My only reservation is diverging from the behavior of rbenv, which just prints a 'version' and a reason it was selected, and is easily machine-parable.

@m4b

Will there be support for bundling static linkers with targets? I believe modulo legal concerns, and some other obscure details, the linking stage in the pipeline is the only stopping point right now from having potentially the most amazing cross compiling system I've ever seen

@mb4 The plan here for the future is that when you rustup target add rustup will give you the option to automatically acquire the right software for your combination of host platform and target platform. So when you install e.g. arm-linux-androideabi, rustup will download the NDK, stash it somewhere, and configure the associated Rust toolchain to use it correctly.

@m4b

Will there be support for adding a linker to a toolchain/target, or how could we do this manually, so that it defaults to this linker when rustc or cargo is invoked with the target which it can link?

I haven't thought of this question before, but it makes sense to focus specifically on linker customization, not just generally configuring the native toolchain. A part of this hypothetical future ndk-managament could be the ability to specify a custom linker.

@mbrubeck

upgrade: I am never going to remember that there is no toolchain add command. I would really appreciate having toolchain add as either an alias or the primary way for adding a new toolchain. I think keeping upgrade as a top-level command for upgrading existing stuff is fine, especially if you think of it as upgrading both toolchains and targets.

OK. Makes sense. The only reasons I haven't added yet are because redundancy, and because install is potentially a better word than add, and because does an add do an upgrade implicitly, or is it just add, and we also need rustup toolchain update?

@mbrubeck

default: with no other arguments, this should show the current default.

Then should the same be true of override? override uses subcommands so should it instead be rustup override show? Then what about default again? Should it be default show?

@mbrubeck

show: I couldn't find this at first because I expected it to be a rustup override subcommand. Could be renamed or aliased to override show, or just override with no other arguments. I would also consider renaming the top-level subcommand to status and potentially adding more information to it over time.

This was a tough one for me. It does logically belong under rustup override show, and in multirust this was even called multirust show-override. In rbenv though it is called rbenv version, which is pretty sweet. For reasons I didn't want to use the word 'version' in rustup so I picked 'show'.

I also considered calling this 'status' and as you suggest putting more info in it, but rbenv does not do that. Furthermore, the word 'show' can be more easily reused for other purposes: toolchain show, override show.

Maybe instead I should put the existing feature in rustup override show, and save rustup status for more broader status (like rustup update vs. rustup toolchain update or rustup update nightly.

@mbrubeck

override add: I appreciate the consistency, but I also kind of expected this to be override set because you can use it to change an existing override.

Yep! But then you probably want to call 'remove' 'unset' ('set' and 'unset' are what rbenv use).

@mbrubeck

override add and override remove: Should take an optional directory argument, so you can e.g. remove overrides from old directories that no longer exist.

Yes. Issue.

@mbrubeck

override list: The output is hard to read (for humans). Many of the commands could probably use separate modes for human-readable vs. machine-readable output (with human-readable as default).

Totally. This is a holdover from multirust.sh. Just needs some attention. Issue.

@mbrubeck

toolchain list: This only lists installed toolchains. Could we get a --all flag to show available toolchains too? And highlight the default and installed ones, like in target list.

Yes. It's complicated though pulling together all the info. Issue.

Thanks for the careful review.