Pre-RFC: Improve access to Rustup components

[Centril]

• ‘default’ - ‘minimal’ plus Rustfmt, Clippy, Rustdoc, and the standard library docs. Note that this does not include the RLS and its supporting data, since that is usually installed by an editor plugin and is usually a good user experience. Using the RLS without an editor plugin is very rare.
• ‘complete’ - ‘default’ plus the RLS and it’s data (docs and save-analysis for the standard library), lldb on Linux, llvm-tools, and any other tools or data added as Rustup components in the future.

Hmm… I think for most users, RLS will be wanted. Thus; I’d recommend making “complete” the default and renaming “default” to something else.

[nikomatsakis]

To follow up on this thought, @nrc you mentioned that the VSCode plugin (etc) can auto-install the RLS, which is true — but right now it does not handle the scenario where the current nightly doesn’t have the RLS installed very gracefully (i.e., the “must rollback to earlier nightly” case). We can of course presumably make it do so, but if we defaulted to including the RLS, this would be a more unusual scenario.

We might have something like:

• minimal
• cli-only
• default
• custom

or whatever.

[nikomatsakis]

(On the other hand, I guess that we expect most users to be on stable…)

[Centril]

We might have something like:

This list seems excellent and aptly named.

While VSCode does install RLS; the experience has not always been great I agree. In any case, I think the installation process would be smoother if rustup just did this and users would not have to go through an extra step. This would also be good for other editors as we can’t assume that everyone will be using VSCode.

[gbutler]

As an extension of these ideas, it would be nice if the initial Rustup install offered options to install additional support for any particular editors:

• vi/vim
• emacs
• …

If that would make any sense that is?

[JeanMertz]

I too have had some “problems” with rustup in my first couple of days working with rust. Some things I’d like to see related to this RFC:

• intuitive toolchains – The concept of different toolchains didn’t really click with me at first, and I had some troubles understanding what was installed globally, and what wasn’t, especially when it comes to some of the extra tooling you mentioned (I believe cargo and rustup itself aren’t tied to a toolchain version, but everything else is, right?). I’m also not even sure if I can actually have multiple stable versions of Rust installed using the toolchain, I don’t believe so (I can only switch between stable/beta/nightly right?) just checked this, you can!

• auto update – I love, love some of the tools that tell me (but don’t yell at me) when I use their tool and there’s actually a new version available. The one that springs to mind is the gcloud utility to communicate with Google Cloud. In fact, that tool also has the “you tried to use this subcommand, but it is not installed, shall I install it for you?” functionality, which is great for discoverability.

• release notes – Tied to auto updates, I like to be able to instantly see what has changed in the tools I’m using. I like the change log windows that VS Code shows me when it’s updated. I don’t like that I have RLS auto-updating on in VS Code and whenever there’s new changes, I can see it updating in the status bar, but I have no idea what’s changed after it’s done updating. Maybe this is just the toolchain-nerd in me, but I like to stay up-to-date with all the latest improvements that can help me become more productive.

• better documentation support – Couple of things here; there’s rustup doc which opens up the “global” documentation, but the first page isn’t that great, it has big/huge headers with one or two sentences after each header, and a link to a deeper page. I feel like this can become much more inviting, interactive and useful with some effort. Second, there’s cargo docs which could use some introduction for new people, it’s not that explorable. It would also be nice if it supported live-reloading of your crate docs while you work on them, but that’s not really relevant to this proposal.

• REPL – this might be out of scope, but some simple REPL (as proposed in this RFC) that comes with some/most of your proposed “profiles”, to quickly fire off some coding experiment is something I would greatly enjoy.

Some (most?) of these are probably out of scope for this RFC, but I wanted to let you know, in case anything pops up that you think is interesting.

All in all, improving the rustup story is definitely something I believe would help newcomers, as it has been something that has caused me to stop a couple of times to figure out how it works and what to do next.

[johnthagen]

Hmm… I think for most users, RLS will be wanted

FWIW, IntelliJ users won’t need the RLS (at least for now).

[nrc]

would you consider providing hooks/templates distributions can use so the missing-component message would fit the distribution

This sounds like an excellent idea!

When running the complete build I think I would want to get new tools as they come out, but perhaps it doesn’t make quite as much sense for the other installations? Could you perhaps expand a bit on your reasoning here?

My basic reasoning is that people don’t seem to like having things installed which they haven’t opted in to. It also complicates implementation since the profile used needs to be preserved in Rustup’s state. I also wanted to avoid thinking about users who already use Rustup without having chosen a profile (although only doing something for ‘complete’ side-steps that.

one thing that greatly confused me when starting with rustup was the notion of toolchains

I think we could definitely do better about making the install instructions self-documenting.

The other thing that I think users would appreciate more visibility into is location of installation

I agree, but I think it is pretty orthogonal to the ideas here.

but right now it does not handle the scenario where the current nightly doesn’t have the RLS installed very gracefully

this is more of an implementation issue, in fact I think it should be somewhat improved already. The extensions use Rustup to manage the RLS, so installing by default won’t make any difference to their handling of it.

While VSCode does install RLS; the experience has not always been great I agree. In any case, I think the installation process would be smoother if rustup just did this and users would not have to go through an extra step. This would also be good for other editors as we can’t assume that everyone will be using VSCode.

Making installation of extensions slicker is a nice motivation. All editors that use the RLS should be able to install it too, not just VSCode.

As an extension of these ideas, it would be nice if the initial Rustup install offered options to install additional support for any particular editors:

This is definitely worth thinking about. Most editors allow installation of plugins from the command line, but I fear this is something that will easily go wrong for users with even slightly customised systems.

Some (most?) of these are probably out of scope for this RFC, but I wanted to let you know, in case anything pops up that you think is interesting.

These are good ideas (especially informing the user when a new version is available), but I think they are out of scope for this RFC.

FWIW, IntelliJ users won’t need the RLS (at least for now).

This is true, and will be for the foreseeable future and is one reason not to install the RLS by default. OTOH, it’s not a huge amount of disk space/bandwidth and is easy to remove.

[Riateche]

Another good hint would be to automatically suggest cargo plugins. It could work like this:

$ cargo tree
`cargo tree` is not a built-in `cargo` command but it's provided by the following plugin:

cargo tree: a Cargo subcommand that visualizes a crate's dependency graph in a tree-like format
run `cargo install cargo-tree` to install this plugin

$ cargo add
`cargo add` is not a built-in `cargo` command but it's provided by the following plugins:

cargo-edit: a utility for managing cargo dependencies from the command line
run `cargo install cargo-edit` to install this plugin

cargo-add: this crate is deprecated in favor of cargo-edit
run `cargo install cargo-add` to install this plugin

install one of these plugins to make `cargo add` command available

This, however, requires a proper registry of cargo plugins, and I don’t know if it exists now.

Also maybe cargo plugins should also be managed by rustup and automatically updated with rustup update.

[tromey]

‘complete’ - ‘default’ plus the RLS and it’s data (docs and save-analysis for the standard library), lldb on Linux, llvm-tools, and any other tools or data added as Rustup components in the future.

I think here you meant lldb on Darwin. We’re not building lldb for Linux. We could… there’s discussion over in https://github.com/rust-lang/rust/issues/48168. Though I tend to think if we’re going to do this we should also ship a gdb for Linux.

[nrc]

Whoops, yeah, that’s a typo

[nrc]

I talked this over with the dev-tools and Cargo teams. There was broad support. There was also a feeling that profiles should be an ongoing thing (and even to make everyone use the default profile if they haven’t opted in to one), and when components are added to a profile, then the component is automatically added for the user.

[djc]

Better integration with rustfmt and clippy is definitely welcome. I think the profile approach to define what gets installed can probably be helpful. Having the stubs sounds like a nice UX improvement.

In terms of tool breakage: I tend to think that the CI should just (I’m aware the “just” here might have deep costs that are hidden to me) not put out an update when any of the tools is broken. If Firefox manages this stuff, why can’t Rust? Back things out that break the tools, or hold back updates until all the tools are fixed. Having nightlies that don’t have some of the tools is a pain in the ass, even if I don’t use nightly most of the time (because now I have to pin my nightly in CI to make sure it has clippy).

As for diskspace/bandwidth: it may not be that much, but I’ve found that having to update my toolchain is definitely an unwelcome break in my process, especially when I have to use nightly (usually in order to use clippy). I don’t know how the size of rls c.s. compare to rustc and std, but I just want to make the point that pulling in stuff that won’t get used is still not a great idea. (Alternatively, could the stub [offer to] auto-install the first time it gets used? That would be a pretty nice experience.)

I really like @JeanMertz’s suggestion of having toolchains be more orthogonal to tools: that is, if you install clippy on stable, it should also be there on nightly (and vice versa, modulo availability).

As another Gentoo maintainer (who was on the other side of the debate @lu_zero mentioned), I’ve found that the Rust project tends to treat the Rust distribution as something of a monolith. This might make sense if you look through the lens of rustup, which is understandably a priority as likely most users use Rust this way. But some of the changes over the past year have made the tools less easily distributable as separate components; for Cargo, the Cargo lockfile (which would enable us to have a more-faithful build of what upstream distributes) has moved into the rustc repo IIRC, and Cargo’s git version numbers now no longer relate to the version numbers in Cargo’s UI (which is now the rustc version). (Our full discussion can be read here, if anyone’s interested.) I’ve accordingly made the Gentoo distribution more monolithic in order to save my own sanity – I don’t want to spend my time fighting against the tide – but, especially when you’re compiling from source, there are definitely downsides to the monolith approach.

Better modularity in rustbuild would also help here.

(Also in terms of distributed components, can someone please clarify the documentation situation?)

In general, it has felt like there’s not a clear contact for packagers. Even if the distributions are understandably not the project’s first focus, it would be nice if there was a bit more clarity on who is responsible for these kinds of issues.

[pietroalbini]

I tend to think that the CI should just (I’m aware the “just” here might have deep costs that are hidden to me) not put out an update when any of the tools is broken. If Firefox manages this stuff, why can’t Rust? Back things out that break the tools, or hold back updates until all the tools are fixed. Having nightlies that don’t have some of the tools is a pain in the ass, even if I don’t use nightly most of the time (because now I have to pin my nightly in CI to make sure it has clippy).

We were not releasing nightlies with missing tools until a few weeks ago (discussion). The main motivation for releasing nightlies even without tools is that nightly releases were rarer with many tools blocking them (rustfmt, rls, clippy), and with the edition coming up we need people to test nightly as much as possible.

(Also in terms of distributed components, can someone please clarify the documentation situation?)

Left a comment on the issue, at the moment we’re only shipping the docs for tier 1 platforms to reduce the load on our CI, since those docs weren’t used too much anyway.

[nikomatsakis]

I really like @JeanMertz’s suggestion of having toolchains be more orthogonal to tools: that is, if you install clippy on stable, it should also be there on nightly (and vice versa, modulo availability).

I too find the “per toolchain” aspect of components sort of confusing, particularly since rustup component add doesn’t need me to specify a toolchain…

[cuviper]

I’ve accordingly made the Gentoo distribution more monolithic in order to save my own sanity – I don’t want to spend my time fighting against the tide

In Fedora, I also gave up on packaging Cargo separately – we now build everything from the rust srpm.

[chriskrycho]

Just here to say we really need to allow hooks to disable installing rust-doc on Windows for CI builds. As it stands, Windows builds on CI take ~5⨉ longer than Linux or macOS just to get through the setup step, because NTFS kind of chokes when dealing with a large number of small files. (This is something I am painfully familiar with from working with Ember CLI in my day job.) I’m happy to pitch in on what’s needed to make that happen if someone points me in the right direction.

[nrc]

I’m currently working on this. I’ll ping you if I can find a way to pull out some tasks for you to work on

[johnthagen]

@nrc If you are referring to @chriskrycho’s Windows rust-doc slow problem, I opened an issue for this: https://github.com/rust-lang-nursery/rustup.rs/issues/1540

[nrc]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.