Add --profile empty support

[kinnison]

This is not necessarily the best way to do this, but I wanted an example up in case someone else wanted to take this further and complete it.

If @rbtcollins is OK with the idea of --profile empty and with this dodgy implementation then we can merge it, otherwise I'd rather this just be used to spark discussion.

If merged, this closes #2970

[likzn]

Hi @kinnison. Can i try to continue to do this work? But i think your implemention is already OK. What can I do to make it more perfecter. Maybe some md should be update and should add some test like rustup toolchain install nightly --profile empty --component rustfmt to check the --component is still work.

[kinnison]

Functionally I think the change is complete. You are quite right that some documentation updates would be a good idea, along with augmenting the tests to verify install with empty profile and a component. I would like @rbtcollins to at least indicate he wouldn't veto this idea entirely though before we merge. If you want to have a go at the docs and additional test, then if you push a branch to your own fork of this branch, and then let me know, I'll pull them into mine so the PR updates.

[rbtcollins]

I have three concerns: are we solving a problem that no one has?

How much or how often will people get confused by the result of using this interesting option?

How usable is it for example a profile with just rustfmt... what does it actually do?

[kinnison]

To answer the first - currently noone has the problem, but this was discussed as an approach to provide rust-analyzer with a way to be distributed through default channels; but still permitting them to regularly update outside of the 6 week release train.

To the second - my hope is "very little" but we could put effort into hiding it a little more if you want. If we did that I'd like to hide complete too.

To the third, I cannot say for certain that all components would work without rustc or cargo available, but my expectation is that they'd at least give reasonable errors.

I'm happy to backburner this, it's not urgent in any sense.

[rbtcollins]

So for all our other channels we have strict bindings. Cargo X belongs with rust Y.

And rustup is very data driven: there is nothing preventing issueing a new channel update with the new version of R-A but everything else unchanged. I don't understand why starting to model a whole new way of thinking about packages is needed.

Perhaps it has to do with the fact that rust-analyzer isn't like the other rust ecosystem components - and for that I would ask why we're installing it at all.

Like, from a software layer perspective,
ra -> rustup -> specific rust toolchain

makes a whole lot more sense to me than
rustup -> ra-proxy-for-channel-X -> rustup -> cargo-proxy-for-channel-Y

Because the later will never work without RA overriding RUSTUP_TOOLCHAIN variables, which will cause trouble as it supercedes toolchain files...

[rbtcollins]

Ok, I've had time to really think about this now.

I think ultimately this depends on whether the rust-analyzer folk want to:

• tightly couple ra to a toolchain, the same as cargo and rustfmt are coupled
• or be a layer above rustup (and/or distro toolchain packages etc)

For the former, we don't need this change.
For the latter, if they want ra to be installed via rustup, we need to design how the interactions with RUSTUP_TOOLCHAIN will work : a ra toolchain called (say) 'rust-analyser' will export RUST_TOOLCHAIN='rust-analyser'. Then rust-analyzer needs to reset that variable before building or interacting with rust - including support for directory overrides, path based toolchains and more.

My personal view is that just offering downloads, like rustup does, for rust-analyzer, and doing platform detection inside IDE plugins (e.g. the vscode plugin) then downloading the ra binary from there will be the most effective approach.

However, if the ra team decide they prefer dealing with RUST_TOOLCHAIN directly and and so on, we can reopen this and implement it then.

Work on hiding complete would be good, but it isn't in this patch. So I'm going to close this as I know @kinnison is currently busy.