progress.rs: don't fail if not a tty

[srwalter]

It's not clear that it was intentional for progress to be disabled when
the output is not a tty. Indeed there is reason we might want to have
progress output in that case. For example, when cargo is invoked by
bitbake, cargo's output will be run through a pipe. Bitbake can parse
out progress updates from that output, but only if cargo actually emits
them...

[alexcrichton]

Thanks for the PR! This was originally done intentionally because most pipes don't handle the commands we later use for things like clearing a line too well (and redirecting to a file looks weird with the progress bar and such). That being said perhaps we could add an option to force the progress bar to show up even if the output isn't a TTY?

[ehuss]

I personally would prefer a config option (which would implicitly support an env var), though not everyone agrees. cc #5721

[srwalter]

Something like this?

[alexcrichton]

Seems reasonable to me! Let's see what others think.

@rfcbot fcp merge

As one question, do others have thoughts on the name? Would we maybe want to generalize --progress slightly or leave it targeted as it is now?

[rfcbot]

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @alexcrichton
• @dwijnand
• @ehuss
• @joshtriplett
• @nrc
• @withoutboats
• @wycats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Eh2406]

Do we want this to be a arg or an env var?
Do we want to add a symmetric way to force it off?

[ehuss]

I still lean towards a config var myself.

Either way, I definitely think it should be generalized with a string. There have been several requests for a way to force it off. The current solution of CI=1 is pretty hacky.

[srwalter]

@ehuss so you want to see e.g. --progress=on and --progress=off?

[withoutboats]

This is the sort of env var I wish we didn't have to have: it would be ideal to me if tools wrapping cargo and piping its output were dealing with a lower level CLI, and the primary user focused CLI were just opinionated about what its output looks like.

That said, users have problems now so I don't know what else to do.

[nrc]

I'm also in favour of a config var and using a string. I'd prefer something more descriptive than on and off, e.g., none and something describing how the default bar is rendered?

[joshtriplett]

Let's default to "auto" (progress if tty) and have --progress and --no-progress for forcing it on and off. Let's not worry about having a "batch friendly progress" beyond printing complete fetches or builds.

[ehuss]

I don't have a strong opinion about the text. One option is to mirror the color option and use auto/always/never. @nrc's suggestion sounds fine, too.

[alexcrichton]

From what others have said and remembering about .cargo/config, I think that's the way to go here as well. We've already got a [term] section for other terminal configuration, and I think this'd fit nicely there. Eventually I'd like to implement an arbitrary --config CLI option as well so you can use that instead of an env var too!

[joshtriplett]

@alexcrichton The ability to say "always" in configuration can lead to some awful breakage if tools expect to parse the command-line output.

[dwijnand]

This feels like the kind of arbitrary additions to the surface area of the CLI arguments, config keys and env vars that we don't want to rush out.

How many users of Bitbake (and similar) are we trying to cater to? How important is this capability for them?

I don't mean to ask that in a harsh way, just trying to understand better.

[bors]

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

[dwijnand]

I've come around to this now, seeing how it mirrors --color.

@rfcbot reviewed

Eventually I'd like to implement an arbitrary --config CLI option as well so you can use that instead of an env var too!

Just cc'ing here too: there's now a proposal for that idea which we might want to consider: #6699

[srwalter]

I don't understand the macOS failure in Travis

[dwijnand]

I've seen package::do_not_package_if_src_was_modified fail a few times on macOS. Restarted.

[alexcrichton]

@rfcbot fcp cancel

I'm gonna cancel the FCP request has this has gone a bit stale. @srwalter would you be up for switching this to a config option like I mentioned above?

[rfcbot]

@alexcrichton proposal cancelled.

[alexcrichton]

I'm gonna go ahead and close this due to inactivity, but it can of course be resubmitted!

[nhynes]

I like this proposal. Cargo wrappers are sometimes helpful and the progress bar really keeps things feeling snappy. I guess an alternative proposal would be to grab the build-plan beforehand and recreate the progress bar as the piped output is updated.