fix(check): Adjust format of 'rustup check' to be like Cargo

[epage]

Discussed at #t-rustup > rustup/cargo output format consistency @ 💬

[epage]

Overall, I'm mixed on the results and can see this going one in several directions

[djc]

Overall, I'm mixed on the results and can see this going one in several directions

Can you elaborate? What do you like/don't like? What potential directions do you see?

[epage]

• Update available causes the rest of the messages to be indented by quite a bit
• Except for Checking, these are descriptions rather than verbs

[rami3l]

@djc I do like this style unification with cargo (I imitate it in my own apps as well from time to time) but I'm afraid without proper JSON output mode this will be fragile... In the long run I imagine the log system can be changed to look more like cargo as well, but I probably won't do that yet in the current version.

[epage]

but I'm afraid without proper JSON output mode this will be fragile

I think I'm missing how json output mode is relevant to how things are rendered.

[rami3l]

but I'm afraid without proper JSON output mode this will be fragile

I think I'm missing how json output mode is relevant to how things are rendered.

@epage This is unfortunate, but currently rustup lacks a stable output format, and our downstreams are basically doing whatever they need to do with the rendering. Basically currently when that's changed we try to make sure that the output is identical or at least similar on is_tty == false and then pray 🙇 I believe the way out here is to first provide something the user can rely on, and then change the rendering.

We've changed the output of rustup show in v1.28 and that has broken quite a bunch of things, I even was involved in several downstream fixes 😓

[epage]

At #t-rustup > rustup/cargo output format consistency @ 💬 I had looked at how people might be using the commands programmatically and it seemed like it would be fine to change this command. Has something changed since then?

With colors mostly handled, I'm looking at the output format part of rustup#266.

As mentioned in rustup#4556, people may be parsing the output of rustup and changing things up could break them. I know Cargo's completions do but that can fail and we can update it.

Here is a proposal to get the conversation started:

check: change

• Unsure the likelihood of someone parsing this
• I'd move the Checking and other status messages to the left, right aligning them, treating them like Cargo status messages

update / install, etc: change

• Unlikely to be parsing the log messages which is mostly how these communicate
• Personally, I would mirror cargo here and move all logging messages to "status" messages controlled by verbosity and then add RUSTUP_LOG to control debug logging

show: maybe change

• The top-level command seems more complex in output, so less chance of people parsing it?
• The sections seem to be inconsistent in casing
• Unsure about whether its worth changing the ------- under headers

show *: no change

• Seem likely people are parsing them
• Not seeing much reason to change these anyways

* list: no change

• Seems likely people are parsing them
• If anything, I could see trying to align on "field" separators (e.g. component listaligning on the - between the component and the platform)
  • However, this is likely not worth figuring out if/how to transition the style

[rami3l]

@epage I think the analysis is, from t-rustup's POV, mostly accurate, though it turned out that people are already parsing rustup show output (corrosion-rs/corrosion#590, #4217, etc.) so I'd expect rustup check to be the same.

It is true that progress reporting etc. are for communication purposes. However there are still parsable elements in the output, such as:

nightly-aarch64-apple-darwin - up to date: 1.93.0-nightly (1d60f9e07 2025-12-01)

Although arguably the number of examples might be relatively small. This is true even for rustup toolchain install I guess, since it also ends with something similar...

Finally, the info: lines you see have already been controlled by tracing_subscriber so RUSTUP_LOG works already (#3879). That's also a new feature from v1.28, although we have implemented it very carefully to minimize output changes for similar reasons, to the point where you might haven't even noticed its existence.

---

Personally though, these messages are not very good-looking, so aligning with cargo is a very good idea IMHO.

The thing is, I do want to push that forward, but there seems to be no real way to find out the impact before the stable release happens. Beta releases are, clearly, not enough otherwise it should've worked on v1.28... Do you have any ideas in that regard?

[epage]

The thing is, I do want to push that forward, but there seems to be no real way to find out the impact before the stable release happens. Beta releases are, clearly, not enough otherwise it should've worked on v1.28... Do you have any ideas in that regard?

At least for Cargo, we don't take this level of caution. We have json messages for some parts of compilation, not even enough to recreate Cargo's output. No other end-user operations have json output at this time, whether it be publish operations, cargo update, etc. We happen to know that cargo --list is parsed for completions, so we're holding off on changing it until we have our new completion system. Otherwise, we take the assumption that human output is exclusively used for humans and callers are responsible for updating if we change the output, is is not Cargo's responsibility for keeping it static.

[rustbot]

☔ The latest upstream changes (possibly #4745) made this pull request unmergeable. Please resolve the merge conflicts.