Support FORCE_COLOR and detect tty

[hugovk]

Fixes #2.

In the absence of special env vars, colour is enabled used when we're attached to a tty, that isn't a dumb terminal.

Normally we don't want to use colour for non-tty, like when piping output.

But GitHub Actions is also not a tty and supports colour, so add support for FORCE_COLOR, which follows similar runes to NO_COLOR, to allow colour logging.

[codecov]

Codecov Report

Base: 100.00% // Head: 100.00% // No change to project coverage 👍

Coverage data is based on head (de23b8d) compared to base (9492a85).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #25   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            3         3           
  Lines           77       106   +29     
=========================================
+ Hits            77       106   +29     

Flag	Coverage Δ
macos-latest	100.00% <100.00%> (ø)
ubuntu-latest	100.00% <100.00%> (ø)
windows-latest	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/termcolor/termcolor.py	100.00% <100.00%> (ø)
tests/test_termcolor.py	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[hydrargyrum]

NO_COLOR is an initiative with a lot of traction and I'm glad it's supported here too

@hugovk I'm trying to compare FORCE_COLOR and CLICOLOR_FORCE to see which one is more widespread.
Does the FORCE_COLOR "standard" have a website? Is there a list of apps/libs supporting it?

[hugovk]

I don't know of a FORCE_COLOR website (but it'd be quite easy to fork https://no-color.org if someone wants to start one).

Doing some quick searches across GitHub repos:

	FORCE_COLOR	CLICOLOR_FORCE
grep.app	3,757 results	1,474 results
github.com	39.7k files	28.2k files

[hydrargyrum]

(Sorry we're diverging about the original PR)

I don't know of a FORCE_COLOR website (but it'd be quite easy to fork https://no-color.org if someone wants to start one).

More than a website, it would be some kind of spec, so FORCE_COLOR has roughly the same meaning in all apps. When looking some of the grep.app results (adding "whole words" option), it seems FORCE_COLOR values are not interpreted the same depending on the app (booleans? integers? any non-empty string?).

[hugovk]

There's a good summary of FORCE_COLOR at jaraco/skeleton#66 (comment):

Request colored output from CLI tools supporting it. Different tools interpret the value differently. For some, just being set is sufficient. For others, it must be a non-zero integer. For yet others, being set to a non-empty value is sufficient. For tox, it must be one of <blank>, 0, 1, false, no, off, on, true, yes. The only enabling value in common is "1".

I made a summary of some Python libraries last year at pypa/pip#10909 (comment), the majority by downloads check for presence of any value.

I use FORCE_COLOR: 1 in GitHub Actions to enable it.

And I'd suggest following the NO_COLOR pattern:

Command-line software which adds ANSI color to its output by default should check for a NO_COLOR environment variable that, when present and not an empty string (regardless of its value), prevents the addition of ANSI color.

So something like (changes in italics):

Command-line software which adds ANSI color to its output by default should check for a FORCE_COLOR environment variable that, when present and not an empty string (regardless of its value), forces the addition of ANSI color.

[hydrargyrum]

Thank you for this thorough investigation!