Project: simplification

[nrc]

We could simplify Rustup a lot. It was built with some very ambitious goals and it is clear that some of things will never happen, but the code is designed to accommodate them causing unnecessary complexity. It is also backwards compatible with very old versions of Rust and Rustup. There is lots of opportunity to reduce complexity. Some ideas:

• remove telemetry (this has never been used and is not that useful in any case)
• remove support for v1 manifests (we should still detect and error out with a message to delete things manually or whatever)
• support fewer ways to install Rust
• use standard logging rather than notifications
• merge some of the crates (probably only rustup and rustup-dist)

cc @rust-lang/cargo for any suggestions of things we should/should not do

[dwijnand]

I'd be happy to assist here. But I've never hacked on Rustup so I'd need a little babysitting.

[h-michael]

I think

• we may delete code for compatible with multirust
• may we need reqwest backend download?
• if we need only curl support, we maybe merge download crate into rustup-utils

My suggestion may be besides the point, sorry.

[alexcrichton]

I'd personally recommend removing all but the curl backend that @h-michael mentioned, and then I'd also look to simplify filesystem transaction handling code. IIRC it's overly complicated and can be implemented far more efficiently than it is today

[kinnison]

This kind of simplification sounds sensible. If you're interested in non-core contributions toward this then I'm very interested in helping.

[seanmonstar]

I'd actually recommend removing the curl backend and using only reqwest. Is there some reason we can't have a Rust tool use more Rust and less C?

[dwijnand]

@nrc @alexcrichton could you give more information regarding "support fewer ways to install Rust" and "simplify filesystem transaction handling code" please? If it's likely to generate a back-and-forth, then perhaps in its own issue.

Meanwhile I've opened an issue dedicated to the crate merging: #1644

[dwijnand]

Also, it's probably good to spin out the curl vs reqwest discussion into a thread and come to a conclusion.

[nrc]

support fewer ways to install Rust

iirc, there are a lot of ways to install Rust via Rustup but the only ones anyone ever uses are dist and the windows installer (which is somewhat separate any way). devs do sometimes install from local disk, but I think that might be able to be simplified by separating it and handling it differently (we can certainly make breaking changes in this case).

[dwijnand]

rustup toolchain install <toolchain>... is the common case.

For rustc devs they also use rustup toolchain link <toolchain> <path> (as documented also in https://rust-lang.github.io/rustc-guide/how-to-build-and-run.html#creating-a-rustup-toolchain), and I think we should keep.

Other than that rustup help toolchain does say:

but rustup can also install toolchains from the official archives, for alternate host platforms, and from local builds.

But I don't exactly see how or where that happens in the code (I'm looking at rustup_mode::update).

[das-sein]

@h-michael @alexcrichton @seanmonstar Created a PR for the removal of the cURL backend. Figure discussion could happen there with respect to @dwijnand 's request for a place to hold one.

[SimonSapin]

remove support for v1 manifests

Were v2 manifests generated for older releases? I think we shouldn’t break the ability for future rustup.rs to install, say, Rust 1.2.0. (I’ve used this to find old regressions.)

[petrochenkov]

cc @brson