`rustup component list` on custom toolchain should work

[cramertj]

Currently this outputs

error: toolchain `mycustomtoolchain' does not support components
info: caused by: invalid toolchain name: 'mycustomtoolchain'

This is called by RLS so it's needed to use the RLS with custom toolchains.

[ianloic]

Well actually, it's called by the VSCode RLS plugin

[kinnison]

What would you expect rustup to do in this situation? simply give you no output?

[cramertj]

Ideally it'd list what components of the toolchain were present just as non-custom toolchains do-- e.g. my prebuilt toolchain dir for Fuchsia includes all of the following:

cargo*          cargo-miri*     rls*            rustfmt*        rust-lldb*    
cargo-clippy*   clippy-driver*  rustc*          rust-gdb*                     
cargo-fmt*      miri*           rustdoc*        rust-gdbgui*

I don't know how feasible this is, but essentially I want using a custom toolchain to "just work" with other existing tools just like using a rustup-provided toolchain would.

[kinnison]

Okay, so this is partially plausible. The issue I have is that rustup {target,component} {add,remove} are impotent on custom/linked toolchains, thus having list be magical might be confusing for some people. One option could be to introduce rustup show proxies [--toolchain X] which would list all the proxies rustup has installed, and indicate for each if the toolchain in question has the target binary available.

E.g.

$ rustup show proxies --toolchain fuchsia
rustc
rustdoc
cargo
rust-lldb
rust-gdb
rls
cargo-clippy
clippy-driver
cargo-miri
rustfmt
cargo-fmt

vs. a hypothetical stage 1 which only had rustc rustdoc, rustfmt and cargo:

$ rustup show proxies --toolchain stage1
rustc
rustdoc
cargo
rust-lldb (missing)
rust-gdb (missing)
rls (missing)
cargo-clippy (missing)
clippy-driver (missing)
cargo-miri (missing)
rustfmt 
cargo-fmt

Would that kind of thing satisfy? I don't want to fake components if I can avoid it.

[luser]

I think the biggest use case here is tools like rls-vscode trying to ensure that your Rust toolchain has a particular component they need. In rls-vscode's case it's rls, rust-src and rust-analysis. The extension has code to parse the output of rustup component list and also to call rustup component add for missing components.

Ideally I'd say that "does this toolchain have these components?" would be a special-case command but either way you wind up with the chicken-and-egg problem of having to first check whether rustup itself supports the new command you're trying to use.

Given that custom toolchains require explicit installation I don't know that it'd be terribly confusing to at least make rustup component list produce useful output for them even if rustup component {add,remove} would continue to not work, as long as they produce useful error messages.

A downside to adding some new command here is that we'd have to go and fix all the tools that invoke rustup component list individually, and it's likely that new tools will be written by people not using custom toolchains that will continue to break in this way.

[kinnison]

We've recently been putting in work which actually makes this harder (but makes it better in the codebase) perhaps we could make it warn if it's not a dist toolchain and then return an empty list on stdout rather than erroring though. @rbtcollins what do you think?

[cramertj]

We've recently been putting in work which actually makes this harder (but makes it better in the codebase)

Custom toolchains are an edge case, and I'm not surprised that supporting them properly would require introducing some additional complexities. However, they're a perfectly valid (and, as more industry adoption occurs, increasingly widespread) usecase, and I think it's important that our tools support them properly.

[rbtcollins]

So uhm.

At a high level doing 'component add' on a custom toolchain is flat out impossible - the whole definition of a custom toolchain is one that doesn't implement the interface for installing components. So IDE's that want to work with custom builds of toolchains will need to be coded to understand that installing additional components is a bespoke operation for those custom builds (e.g. tell the user to do it, rather than complaining).

Our concept of 'component installed' is actually listing metadata, not interrogating installed files; I think perhaps rls-vscode is heading in the wrong direction here, and should instead be trying to execute the thing it needs, rather than querying whether it is installed first.

Now, the question is what does useful output for a component list on a custom toolchain look like. I think its a category error to give an empty list: code that tries a list then an add will proceed to the add step inappropriately, and we will then have to debug and work back to the cause (that the toolchain is custom).

I think more machine readable output would help, in particular I'd like to start doing yaml or perhaps JSON error codes for things like vscode, so that UI tweaks don't destabilise higher level tools.

[luser]

I think more machine readable output would help, in particular I'd like to start doing yaml or perhaps JSON error codes for things like vscode, so that UI tweaks don't destabilise higher level tools.

Fully agree on this. I'd argue that JSON is the de facto standard for machine readable data in cases like this (for better or worse) and given that cargo already has --message-format=json it would seem reasonable to expect rustup to do so.

If you do implement this the biggest design decision I think you should make up front is whether JSON output means "one JSON object written to stdout per invocation" or "a series of JSON objects written to stdout per invocation, one per line". You could make an argument either way.

cargo writes an object per line but it's mostly transmitting status messages about the build so that makes sense (if you go that route you should also support the --message-format option so tools can consume rustup output and format it nicely).

Writing a single JSON object per invocation would mean that you could define a JSON schema for each command's output (which is super nice to have in documentation).

Either way you'd want to define what JSON output means when errors occur etc. Do JSON formatted errors get written? To stdout or stderr? Those sorts of things.

[rbtcollins]

@luser yes, all of those things. Thanks for the pointers to the cargo behaviours, I think matching those as a baseline is a good idea; rustup too has N>1 status message to send, so the design domain is very similar.

[kinnison]

@cramertj My current thoughts on custom toolchains is that they tend to be used primarily by compiler/stdlib devs and as such don't need component support. Instead we need to make it easier for those devs to publish channels which can then be installed from, supporting the combination of components which the devs wish to publish. Such custom dist channel support will need some deep changed to rustup but would, IMO, be much better than a superficial fascia overtop custom toolchains to fake up components.

[Nassiel]

Hi, sorry, I know this is not a critical issue, but although I agree with Kinnison I don't know if there are any steps to happen or if this is going to stay locked here for a very long time 😞

[kinnison]

I did start to write up a starter-for-ten on how custom toolchain providers might present channels and how Rustup might consume them coherently - https://hackmd.io/X_xhHKHnRnycDDJURv2M4A?view - it is still a very basic idea though. If @Nassiel wanted to participate in design and possibly subsequent implementation, we can arrange conversations.

[Nassiel]

Hi @kinnison sure, any discord where we can chat?