Please support a "system" toolchain

[joshtriplett]

I'd like to be able to test things using my system-installed version of Rust, and also use nightly Rust via rustup. To support this, I'd love to have support in rustup for a "system" toolchain, which would allow cargo +system, or setting system as the default and using cargo +nightly.

When using the "system" toolchain, the various rustup-managed binaries would simply forward to the corresponding system binaries.

[joshtriplett]

Note that rustup toolchain link system /usr provides roughly the desired behavior; I'm simply suggesting that rustup support doing that by default for a system installation of Rust so that it works out of the box.

[qmx]

This is going to be even more desirable now that rust-1.31.0 (2018) arrived at debian testing :)

[kinnison]

Is it really necessary to do this automatically? Also when should rustup decide to do it? Only on rustup-init ? Or perhaps on any rustup update ? Should it reserve the term system? This kinda feels like something better solved as documentation rather than behaviour.

[vi]

As a minimum it should suggest rustup toolchain link in this message:

info: downloading installer
warning: it looks like you have an existing installation of Rust at:
warning: /usr/bin
warning: rustup should not be installed alongside Rust. Please uninstall your existing Rust first.
warning: Otherwise you may have confusion unless you are careful with your PATH
warning: If you are sure that you want both rustup and your already installed Rust
warning: then please reply `y' or `yes' or set RUSTUP_INIT_SKIP_PATH_CHECK to yes
warning: or pass `-y' to ignore all ignorable checks.
error: cannot install while Rust is installed

Continue? (y/N)

Maybe it there should be easy interactive choice leading to linking system toolchain, not downloading any additional toolchains and making system toolchain default.

It should be straightforward to enable cargo +nightly build without touching the default way too much.

[kinnison]

@vi That's not a bad idea at all. If you wanted to submit a PR then that'd be great. @joshtriplett Do you have any preference on wording if we were to resolve this in that way?

[joshtriplett]

@kinnison Yeah, I'd love to see the "rustup should not be installed alongside Rust" warnings removed, and replaced with something like this:

It looks like you have a system installation of Rust in /usr (/usr/bin/rustc). Rustup provides access to multiple toolchains in parallel, with syntax like cargo +stable build or cargo +nightly test. Rustup will add your system Rust toolchain as +system. You can see all your Rust toolchains with rustup toolchain list, and set your default toolchain with rustup default toolchain-name.

[vi]

Why the warning "should not be installed alongside Rust" exists in the first place?

Are there any problems apart from obvious possible confusion of user-callable frontends (rustc and cargo)? What can go wrong with that setup?

[Diggsey]

rustup needs to be first on PATH or else it will be unable to intercept the calls to cargo and rustc.

[vi]

I sometimes manually call /usr/bin/cargo or ~/.cargo/bin/cargo, not relying on PATH at all.

Am I right that this interception is only needed for initial calling into rustup-managed toolchain, not for inner working of that toolchain (such as cargo calling rustc)?

PATH-based interception is only one of rustup features, not necessarily the main one. Should it be relied upon that only this interception is "at stakes" when combining rustup with existing installation or there can be other, non PATH-interception-related problems?

[kinnison]

I believe rustup will attempt to set the PATH properly in the subordinate cargo so in theory PATH prepending is not needed if you explicitly invoke a rustup proxy. The warning is useful otherwise people might be confused between running cargo in their shell and running it from an IDE not launched from somewhere which sets PATH pthe same. I like the idea of Josh's suggestion though, basically replacing the "are you sure" with a basic warning that this might confuse and an auto-creation of the system toolchain pointing at the appropriate prefix.

That'd basically entail looking for the existing cargo/rustc (already done) stripping bin/cargo off the end, and then sticking that into an Option for use later for a system toolchain to be created/updated at the end of the install step.

[Diggsey]

@kinnison I think in that case it may be worth updating rustup show and other commands to check if rustup is first on the PATH, and print a warning if it's not, or just always show "system" as the active toolchain, and return an error if you try and change that.

[kinnison]

Hmm, interesting idea, I guess rustup show is sufficiently safe for that kind of thing, but perhaps not all rustup commands? Then again, if you know you're invoking rustup and it's not a command which needs greppable output (and while we don't guarantee output formats, people do come to rely on them) then I suppose any could warn. Perhaps even all warn, but to stderr... However switching to the system toolchain as a result seems a step too far in terms of changing behaviour which people may be relying on.

[Diggsey]

@kinnison well the idea is not to switch to the system toolchain.

To me, rustup show is supposed to show which toolchain will be used when I use a command like cargo build - if rustup is not able to intercept those commands, then rustup show should always show "system" as first toolchain, or else it will be lying.

[vi]

But ~/.cargo/bin/cargo's toolchain should also be displayed by rustup show even if it is not in PATH.

rustup show output may be longer and may contain a warning if rustup's default toolchain is not the same as actual default toolchain. The warning should be absent if there are not Rust tools in PATH at all.

[kinnison]

I think to fully understand what's being suggested @vi I'd appreciate it if you could give me some worked examples in a comment. I appreciate I'm probably being a little slow here, but we're talking about a potentially quite large UX change so I want to know what I'm agreeing to.