Enable colours when FORCE_COLOR env var is set

[hugovk]

What's the problem this feature will solve?

pip 22 now uses Rich for installation progress bars and some error handling, which gives us pretty colours!

Colour can help diagnose problems, and a common place for pip and the need to diagnose problems is on a CI.

However, because the GitHub Actions isn't a tty, output of tools which autodetect the terminal output is usually monochrome. That's why many tools and CI setups use the FORCE_COLOR environment variable, and/or command-line options to turn it back on.

The pip CI included (#10830):

pip/.github/workflows/ci.yml

Lines 14 to 17 in 4a508c2

	env:
	# The "FORCE_COLOR" variable, when set to 1,
	# tells Nox to colorize itself.
	FORCE_COLOR: "1"

However, pip itself (and Rich) don't use FORCE_COLOR, meaning we get monochrome output:

Compare with nox:

https://github.com/pypa/pip/runs/5177210581?check_suite_focus=true

And pytest:

https://github.com/pytest-dev/pytest/runs/5185781927?check_suite_focus=true

Describe the solution you'd like

Enable colour when FORCE_COLOR is set.

For reference:

• pytest issue, PR and docs
• nox issue and PR
• tox PR
• pypa/build PR
• Colorama WIP PR
• Node.js docs

Alternative Solutions

Get Rich to support FORCE_COLOR directly. This was considered in 2020 but rejected in Textualize/rich#343 to leave it up to the developer to support it.

But Will said "I may yet relent on this. I try to be pragmatic!" so it may still be a better option :)

Additional context

I'm not specifically requesting it here, but could be worth considering also disabling when NO_COLOR is set: https://no-color.org/

Similarly not requesting it here, but for completeness I'll mention pytest also has this command-line option:

  --color=color         color terminal output (yes/no/auto).

And nox:

  --nocolor, --no-color
                        Disable all color output.
  --forcecolor, --force-color
                        Force color output, even if stdout is not an interactive terminal.

Whereas pip only has the negative:

  --no-color                  Suppress colored output.

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[potiuk]

Yeah. That would be indeed very useful. Colors in CI are great for visual communication (as otherwise you end up with big blob of text) - especially that often in Ci you enable pretty verbose output to be able to diagnose problems. Nany tools allows forcing colors indeed so it woud be useful to have it in 'pip'. Happy to help and create a PR for that one if preferred way to do it is agreed to by the maintainers..

[hugovk]

Let's also ping @willmcgugan from Rich: do you think it would be better for Rich itself to use FORCE_COLOR?

I think it would: better to do things upstream and it would mean other users of Rich would also benefit.

Please let me know if I should instead comment in Textualize/rich#343 or open a new Rich issue.

[willmcgugan]

I don't want to add FORCE_COLOR to Rich because on some apps FORCE_COLOR=0 would mean "force color off", but on other apps FORCE_COLOR set to anything means "force color on", i.e. the exact opposite.

Since there is no sane standard at the moment, I'd prefer to leave it up apps to decide how to do it. Fortunately it is trivial to implement it how you wish.

[potiuk]

Agree with @willmcgugan :). Also not everyone uses rich (though I think it gets close to becoming de-facto standard in Pyhon world) so setting the standard here by rich brings no big value as just setting "FORCE_COLOR" for the whole CI would not cut it.

[hugovk]

Okay, thanks Will!

---

For pip:

I checked the top 5,000 PyPI packages (with help from this and that):

Package	Use	PyPI downloads Feb 2022
pytest	NO_COLOR any value -> off FORCE_COLOR any value -> on	35,247,938
colorlog	FORCE_COLOR any value -> on NO_COLOR any value -> off	25,798,377
build	NO_COLOR any value -> off FORCE_COLOR any value -> on	1,301,248
nox	FORCE_COLOR any value -> on NO_COLOR any value -> off	923,535
molecule	FORCE_COLOR truthy -> on FORCE_COLOR falsy -> off NO_COLOR any value -> off	267,105
Js2Py	FORCE_COLOR any value -> on	199,216
enrich	FORCE_COLOR truthy -> on FORCE_COLOR falsy -> off NO_COLOR any value -> off	403,707
colored	FORCE_COLOR=1-3 -> on FORCE_COLOR=0 -> off NO_COLOR any value -> off	162,316
Total		64,303,442

The top four all just check for any value of the env var (difference in the order of precedence).

Those four account for over 98% of the downloads of these eight.

So how about pip (55%) follows the pytest pattern?

[ssbarnea]

I have some good news, apparently colorama also approved adoption of a sister change tartley/colorama#230 (comment) and will likely be merged soon.

Based on the stats I seen, I think we have a clear winner. I know that two vars is less ideal but having this is still far better than one variable for each command line tool!. At least people recognized the pattern and moved on.

To be honest any generic environment variable is much better than MY_TOOL_NAME_USE_COLORS as that one that not scale at all. I see extremely unlikely that someone would want to enable colors only for one tool while not enabling them for other. Even if they want they can always override with FOO=bar cmd args ....

Funny that I see myself explaining the same thins I already did two years ago on rich, while the proposal was refused. I do hope that maybe in 2022 we might be able to realize that making the life easier for most users should be a priority.