rustup.rs future work

[brson]

This is a brain dump of the work I believe is left to complete the transition to rustup.rs.

cc @Diggsey @alexcrichton

Polish existing UI

I'm not sure what else needs to happen but I know there are some commands
that still don't look nice to me. I've taken a pass at the most important ones but not all.

Also go over common error cases and make sure they look good.

Install to $CARGO_HOME

This will probably need another version bump to know to delete the bins from ~/.multirust.

Add tests for delete-data which right now doesn't work correctly because the bins in ~/.multirust/bin get clobbered.

Reconsider windows install dir

Right now multirust-rs installs to AppData/Local/.multirust. It should maybe not use a dotfile here. Use whatever scheme Cargo does.

Make self-install frobbing of $PATH foolproof

I haven't looked at the code for how self install sets up the path,
but I do have opinions about how it should work.

It should both install and remove the path by default, with an option
not to. Because shells typically need to be restarted for this to work
it should probably also emit a shell-specific file that can be
immediately sourceed as well.

Overhaul self-upgrade procedure

The way multirust-rs treats no arguments as a self-upgrade is prone to error, and takes away our
ability to do useful other things with no arguments. Change the name of the installation program
to multirust-setup and only run the 'self install' on no arguments when the binary has that name.

Normalize toolchain names

At the moment multirust-uses the toolchain name as provided by the
user to identify toolchains, even their location on disk. Instead,
ToolchainDesc should be constructed immediately when Toolchain is and
all further internal references to toolchains should be the fully
expanded form. When printing toolchain names to the user either use
the one they refered to or come up with a scheme for automatically
shortening toolchain names, i.e. maybe host toolchains don't get
expanded to $triple-channel.

Create the "rustup" command

When run as "rustup", multirust-rs will present a new, subcommand-based interface. I haven't
thought it through yet but it will probably be something like "rustup default set|show",
"rustup toolchain update|list|remove", "rustup override set|list|show|remove",
"rustup target add|list|remove".

This will reduce the amount of clutter in --help and group
functionality that belongs together, make room for further
subcommands.

Add rustup-setup

Exactly like multirust-setup but rebranded.

Move install dir from .multirust to .rustup.

Need to make sure the metadata format can coexist with rustup.sh.

Make sure the download tracker isn't clobbered by verbose output

I suspect that verbose notification don't play well with the download
tracker but haven't looked.

Fix "invalid custom toolchain name" error

I believe this error is printed in cases where the toolchain is not custom.

Don't manipulate $PATH

I don't think multirust-rs should need to manipulate the path variable.
multirust.sh only does it as a compatibility hack.

Eliminate MULTIRUST_RECURSION_COUNT

I'm not sure what case this is catching but it shouldn't be necessary.

Edit: On second thought, this seems like a reasonable precaution.

Investigate assert in "multirust update foo"

When "foo" is not a valid dist toolchain this command asserts

Make --help look better

It prints in alphabetical order, presenting the commands in a way that
doesn't make logical sense. Converting to a subcommand-based rustup
might make this better, since there would just be fewer options.

Default to stable

Instead of having to explicitly type "multirust default stable", stable
should just be the default.

Make "multirust update" only update installed channels

Right now it updates "nightly", "stable", and "beta", plus any
tracking toolchains. Instead it should only update installed
toolchains, or if no toolchains are installed, just stable.

Use hardlinks instead of softlinks for self installation / --link-local

Softlinks need admin access on windows, which is a pain. I think
hardlinks should be fine since we are in control of all the sources
and destinations.

Add tests for non-build hosts

Installing compilers for arbitrary hosts works, but has no tests.

Set up rustup.rs

This will involve routing DNS to our proxy server and making
sh.rustup.rs and win.rustup.rs proxy to the appropriate resources.

Add download / resume caching

Add cargo fallback

When using a custom installation without Cargo, multirust should
fallback to using nightly, beta, then stable cargo.

Add GPG support

Begin work on NDK support

Right now I intend to make this a standalone library/cargo subcommand
that rustup links to, with support for acquiring NDK,
cross-deployment, and cross-testing.

Begin work on Win32/msi GUI

On windows, the installation experience needs to be better. Right now
I'm hoping that msi offers enough hooks that we can call into rustup,
presenting a familiar experience while still using the common
installation code.

Begin work in VisualRust integration

[brson]

My wip

[brson]

cc @aturon

[alexcrichton]

Super excited about all this! 📻

[tilpner]

I assume you mean multirust update <toolchain> --link-local by Use hardlinks instead of softlinks for self installation / --link-local.

Would this mean a recursive copy via hardlinks on Linux, as you can't hardlink a directory? (think cp -al)
Do you plan for a fallback to symlinks for cross-device --link-local?

[retep998]

Directory junctions are a valid alternative to symbolic links that are usable without administrator privileges, although there's no nice function to create them. libstd does have a function that does so but is currently internal and used for tests only, perhaps consider exposing that.

[brson]

I assume you mean multirust update --link-local by Use hardlinks instead of softlinks for self installation / --link-local.

Yes.

Would this mean a recursive copy via hardlinks on Linux, as you can't hardlink a directory? (think cp -al)
Do you plan for a fallback to symlinks for cross-device --link-local?

Oh, I didn't realize you can't hardlink directories. I guess that won't work. Perhaps I'll need to look into junctions as @retep998 suggests.

[jan-hudec]

Use hardlinks instead of softlinks for self installation / --link-local
I think hardlinks should be fine since we are in control of all the sources and destinations.

No, they wouldn't, because no, we are not. In case of

multirust update system --link-local /usr

we definitely don't control the target, and the target will be updated by other means. That works just fine with symlinks, but wouldn't work with hardlinks.

And to be honest, that is about the only use for --link-local I see.

Also, I am currently using that and it seems to work fine.

[Diggsey]

A number of these can be ticked off 😀

[brson]

Considering this old braindump done.