Add a configuration option to force progress output

[srwalter]

Setting term.progress to "always" will cause progress updates to be
output, even if the output device is not a TTY. The default is "auto",
which is the current behavior.

Re-open of #6395

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Eh2406 (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[srwalter]

@alexcrichton did I understand correctly that you wanted to see a "progress" option in the [term] section of config?

[Eh2406]

cc #8165 (comment) how are the 2 PRs diffent / similar?

[srwalter]

Different in how to control it; I'm using a config option/env var, rather than a command line switch. I'm not opinionated on that point, but in my previous MR others seemed to prefer config option.

Other MR seems to be doing more, but I'm not exactly sure what.

My intention is to allow bitbake to be able to parse progress output so it can show the user its own progress bar. bitbake already has support for matching a regex, but bitbake redirects all command output to a file. Today cargo detects that it's not writing to a tty and disabled progress output.

[alexcrichton]

I believe the commentary on #8165 is not related to how this is enabled but how it doesn't really make sense to parse the output but rather it would likely be much more beneficial to parse json messages instead.

[srwalter]

That is true, however JSON doesn't help me. bitbake wants a regular expression to match current task and total number of tasks, which is what most build systems already display for human readers, including cargo. JSON may be useful for some situations, but it wouldn't help me. I just need exactly what cargo already generates for progress.

[ehuss]

I personally would not parse the progress bar, that seems like asking for trouble.

However, I don't care enough to specifically reject adding a configuration value (it may be useful for other purposes).

If we add a configuration, I would prefer something like what I prototyped (as discussed here, there's an old patch here). That is, the config can be:

[term]
progress = 'auto' # or 'never' or 'always'

# Or, if you want to specify a width:
[term]
progress = { when = 'always', width = 100 }

I would also encourage you to coordinate with @mchernyavsky since you both have posted a PR around the same time. I'm not sure if they have made any more progress.

[bors]

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

[ehuss]

Closing, as this has been essentially implemented in #8165. Discussion of adding more JSON messages can happen in #8283.