Pre-RFC: Improve access to Rustup components


#21

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.


#22

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.

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.


#23

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…


#24

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


#25

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. :grimacing: (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.


#26

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


#27

@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