Rustup roadmap and help needed


Hi there.

Today, @Diggsey, @alexcrichton and I did some triage of the rustup issue tracker to try to get a handle on what needs to be done next.

rustup is a project with fairly limited scope, but there are some important features left to implement, and lots of bugs, and lots that needs polish. It could use more contributors, so @Diggsey and I will try to keep the issue tracker better triaged, and escalate tasks that are amenable to contribution.

There are only a few big features on the roadmap:

  • Update signing
  • Windows GUI
    • rustup on windows looks pretty bootleg still. @Boddlnagg has some work finished on this but I’ve dropped the ball on pushing it forward.
  • Component dependencies
    • The rustup rls package requires rust-analysis and rust-src, and today they must all be installed explicitly. Fixing this will require defining an extension to the rustup manifest format, then modifying rustup.
  • Default-optional components
    • The docs package is always installed today, but not always desired. Again the manifest format needs to be updated.
  • Overrides that can be checked into version control
    • Today rustup version pinning is local, but applications stuck on nightlies (like servo) frequently want a way to express this in their VCS, ala rbenv

Volunteers are needed for these, though the windows GUI and update signing issues are large projects. The overrides feature I intend to do myself.

There’s an outstanding problem with both rustup and rustc not recognizing the 2017 build tools. @retep998 has some

code that can do the discovery, but it needs to be imported into both rustc and rustup. This is on the 1.18 milestone.

If anybody can help move that forward it would be appreciated, though otherwise I will get to it sometime this cycle.

Next, there are a number of smaller issues that look relatively important to me, and are mostly relatively easy to pick up without much context:


Is “upload rustup and its dependencies to” ( on the roadmap anywhere? What help would be needed to get to that point? It would make packaging (and ongoing maintenance of packaging) far simpler.


I’m afraid it is not a priority for me, and it is not clear how it would work technically. Having cargo install rustup is quite a dependency inversion.


Could you give some more details of how this would work / be useful? Currently rustup is designed to be installed before you have a working cargo/rustc, and in fact may fail to install if rust is already installed, so it’s not clear what it would mean for rustup to exist on


Having it available as a crate, and all of its dependencies available as crates, would make it much easier to package and maintain rustup in Linux distributions. That, in turn, makes it easier for people to experiment with nightly Rust, or install a cross-compiler.


It’s a matter of being able to build rustup using Cargo, and have the dependencies available to do so. (And the assumption would be that you have rustc and cargo installed by some other means, not via rustup.)