Respect NO_COLOR and FORCE_COLOR

[hugovk]

• https://no-color.org/
• Support NO_COLOR to disable colored output pytest-dev/pytest#7464
• Add support for NO_COLOR and FORCE_COLOR pytest-dev/pytest#7466
• Support NO_COLOR #7
• Support FORCE_COLOR and detect tty #25

[blueyed]

FORCE_COLOR is not really a (community) standard.

From all the projects (apart from pytest where you've added it) I've checked out locally only https://github.com/qix-/better-exceptions uses it, but requires it to be "1" then - unlike pytest where any value forces color (similar to NO_COLOR).
(Other projects use specific vars (ANSIBLE_FORCE_COLOR, VAGRANT_FORCE_COLOR, …), similar to pytest using PY_COLORS.)

[hugovk]

Yeah, FORCE_COLOR definitely isn't anywhere as widespread as NO_COLOR, but I think FORCE_COLOR is a useful addition (actually, it won't be useful here until there's also tty detection).

There's also a PR (nearly one year old!) for Colorama (tartley/colorama#230) that adds both, and checks for presence, regardless of its value. I think that makes sense, to use the same way of checking for FORCE_COLOR as NO_COLOR.

Thanks!

[tomwatson1024]

AIUI this change means that termcolor always respects NO_COLOR - but what if the user doesn't want to use that environment variable? In particular, termcolor now has different behaviour based on the user's environment, which wasn't the case before.

I ask because I maintain a (proprietary) library using termcolor that allows users to:

• explicitly enable color;
• explicitly disable color;
• allow color autodetection, using NO_COLOR.

With this change, I can no longer explicitly enable color (without patching os.environ)!

Perhaps termcolor.colored could take a keyword argument controlling use of NO_COLOR?

[hugovk]

Yes, that's correct, NO_COLOR overrides termcolor (and will also override FORCE_COLOR when it's added).

The idea is the person running a command-line tool has an easy way to disable colour output across all tools, and they may not be able to change the tool code itself.

Perhaps termcolor.colored could take a keyword argument controlling use of NO_COLOR?

Then we have a bit of an "conflict":

• dev wants colour, so uses colored
• user doesn't want colour, so uses FORCE_COLOR to override colored
• dev wants colour, so uses colored(ignore_force_color=True) to override FORCE_COLOR that overrides colored
• next step: REALLY_FORCE_COLOR? ;)

With this change, I can no longer explicitly enable color (without patching os.environ)!

Yeah, that might actually be a reasonable way to do it: if you really don't want NO_COLOR, just unset it.

import os
import termcolor

del os.environ["NO_COLOR"]

termcolor.cprint("hi", "green")

[tomwatson1024]

I think it's a good idea to respect NO_COLOR by default, as it enables devs who don't want to think too much about color support to have the "right thing" happen, without writing any extra code.

However, I do think there's value in allowing the developer full control over color if they want it. For example:

• an application that implements its own color selection logic, as in my comment above. In this case the developer is (hopefully) providing means for the user to disable color and, if not, well that's on them - they've opted in to the fine-grained control!
• colored text that is not directly written directly to the user's terminal - instead it's saved to a file for later use, or compared to output in e.g. unit test.

I'm sure there are other cases, too, where it's useful for coloration to be "pure", in the sense that its behaviour is consistent regardless of the user's environment.

"Make simple things simple, and complex things possible"

That said, I appreciate that termcolor is ultimately open-source and provided for free! If you prefer to go a different route, that's entirely your perogative.

[hugovk]

Now I re-read https://no-color.org/ I see it's been updated to clarify some things:

2. How should configuration files and command-line arguments be processed in the presence of $NO_COLOR?

User-level configuration files and per-instance command-line arguments should override $NO_COLOR. A user should be able to export $NO_COLOR in their shell configuration file as a default, but configure a specific program in its configuration file to specifically enable color.

This also means that software that can add color but doesn’t by default does not need to care about $NO_COLOR, because it will only ever be adding color when instructed to do so (as it should be).

So I think this supports your suggestion of a keyword argument 👍

Now the really difficult bit is finding a name for the keyword argument!

Do you have any ideas? Do any other libraries at https://no-color.org/ have such an option, and what do they call it? I don't think any of the Python libraries support it.

[hugovk]

PR #25 adds tty detection and support for the FORCE_COLOR env var.

[hugovk]

Please see PR #38 to add parameters to override the environment variables.