Cargo script should only output messages from the script for no-change builds

[Timmmm]

Problem

With cargo script, if nothing has changed in your script so nothing needs to be rebuilt, then you shouldn't see any noise from Cargo; only output from the script itself.

Currently you always see Finished and Running lines like this:

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.22s
     Running `/home/tim/.cargo/build/f2/c9ee52a23ab051/target/debug/test`
Hello, world!

Proposed Solution

No response

Notes

No response

[epage]

This was split out of a conversation starting at #12207 (comment)

[epage]

Notes from that thread:

• Addressing the output is currently marked as a non-blocker for stabilization of Cargo script
  • The proposed long term solution is Console output should better reflect the build process #8889
• Concern was also raised with replaying of warnings
  • Personally, I think this should remain

[epage]

@Timmmm could you get into the end-user impact to help us understand why you feel a short term solution should be used rather than waiting on #8889?

[Timmmm]

Well I think the main use of cargo script is to make CLI tools, where you might have previously written them in Python or Bash. For that use case you don't want some random messages from Cargo every time you ran them.

I would like to suggest using cargo script at work instead of Python for these sort of things (Python actually sucks for this use case despite its popularity), but if they see these messages every time they run a command it's going to be a complete non-starter.

#8889 looks like it will take a long time, whereas we can fix this particular issue we a very small PR.

[weihanglo]

It is quite related to #8743 I guess.

[epage]

Good point about #8743. That is more general than cargo script and so we probably shouldn't close this in favor of that but there is relevant conversation there.

Limiting this to unchanged builds is a new idea.

Not sure what I think of this but one alternative idea:

• We generally place Finished behind an unchanged check
• We always move Running to one extra level of verbosity for all types of cargo run

whereas we can fix this particular issue we a very small PR.

Not thrilled with that PR tracking this special state as a verbosity level

[User1785604260]

I've only been loosely following along and haven't actually tried cargo script out yet, but I have several personal CLI tools that I'd love to try switching over to Rust.

To not interfere with the output of my programs, I'd only expect to see any Cargo output at all if the script ultimately fails to build. So even for a script-changed build, I wouldn't want to see output unless the build failed.

I'd expect to see Cargo output only when I'm building the script file without actually running it. (I'm not sure what the command is to do that.) Saying "just build but don't run" is when I'd want to see warnings, etc. I don't think I would end up switching any of my CLI tools over if I had to add extra logic to (sometimes) strip out Cargo output to process the results.

(Apologies if this scenario has already been covered and I don't realize.)

[Timmmm]

So even for a script-changed build, I wouldn't want to see output unless the build failed.

The problem with this is that it can take a long time to compile some Rust programs. I wouldn't want users to be sitting there waiting for a minute while the script appears to be frozen with no output at all.

It could definitely be a much more minimal output for cargo script though (e.g. just a single progress bar). But I don't think it's as much of a deal-breaker.

Not thrilled with that PR tracking this special state as a verbosity level

Yeah I wasn't sure about that either.

We always move Running to one extra level of verbosity for all types of cargo run

I dunno I kind of like this for normal cargo runs. It is handy because sometimes I later want to run the binary directly and I can easily copy the path. Also it's a good sanity check that it's actually running what I think.

I don't think I ever really care about the Finished message though. It's kind of redundant.

I did think about adding a flag to just suppress Finished and Running - I think that would be an acceptable solution too, but I'm not sure what you'd call it! --quiet-running? --quietish? It felt weirdly specific too - a whole CLI option just to disable two messages? I dunno. But if someone okays it I can implement it. Definitely better than the status quo.