Support `FORCE_COLOR` env var

[MicaelJarniac]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the FAQ and general documentation and believe that my question is not already covered.

Feature Request

Add support for the FORCE_COLOR environment variable. When set, regardless of value, all output should have colors enabled, as if the terminal supported them.

Some projects that use this:

• Pytest
• Nox
• Tox
• Rich
• Mypy
• build

Related:

• [REQUEST] Enable colours when FORCE_COLOR env var is set Textualize/rich#2425
• Provide a FORCE_COLOR variable? wntrblm/nox#502
• Enable colours when FORCE_COLOR env var is set pypa/pip#10909
• Support FORCE_COLOR env var astral-sh/ruff#5499
• Support FORCE_COLOR env var pre-commit/pre-commit#2918

[MicaelJarniac]

Worth noting, the main reason behind this is to have colored output when run in places like GitHub Actions.

I did experiment with using --ansi, and it did enable colors, but also ended up duplicating a lot of the lines.

I believe there may be something wrong with the way it redraws a line when it needs to update it.

Without --ansi (13 lines total):

With --ansi (145 lines total):

[Secrus]

how does FORCE_COLOR standard corelate with NO_COLOR? Do you have any specifications or documentation, please?

[MicaelJarniac]

Of course, sorry.

• https://no-color.org/

It seems that NO_COLOR takes precedence, so if it's set, color should absolutely not be used.
Here's how a few projects do it:

Pytest

• https://github.com/pytest-dev/pytest/blob/97ed533f63d5780a05702a711555cb6744247a37/src/_pytest/_io/terminalwriter.py#L31-L34
• https://docs.pytest.org/en/7.0.x/reference/reference.html#envvar-NO_COLOR

Tox

• https://github.com/tox-dev/tox/blob/9fcbf1bad397e8b96225ce4e9d3a1fca19616cb4/src/tox/config/cli/parser.py#L288-L291

Rich

• https://rich.readthedocs.io/en/latest/console.html?highlight=FORCE_COLOR#environment-variables

Mypy

• https://github.com/python/mypy/blob/781dc8f82adacce730293479517fd0fb5944c255/mypy/util.py#L523

build

• https://github.com/pypa/build/blob/6b884ae7dbada2aee10da25394bb0766c9ae8714/src/build/__main__.py#L40-L47

[gsemet]

I agree. NO_COLOR forces to disable the color, but there are instances where there is no tty but we know colors are supported (github actions, or gitlab CI). Supporting a way to "allow color despit no tty" use case is a must.

Conan uses "NO_COLOR" and CONAN_FORCE_COLOR, with a precedence of NO_COLOR over CONAN_FORCE_COLOR.

I vote for POETRY_FORCE_COLOR to allow enabling colors only in poetry if need be

[MicaelJarniac]

I'd say to support FORCE_COLOR, as to avoid the user having to constantly search around for what unique variable each tool uses, and maybe a POETRY_COLOR that can be set to something like "true" or "false", and takes precedence over both NO_COLOR and FORCE_COLOR, in case the user needs to configure just Poetry separately.

[adam-grant-hendry]

Would this be different from setting ANSICON to a non-empty value?

From #10

As a workaround, you can set the ANSICON env-var to something non-empty to force ANSI support.

The relevant code from the source is here.

[adam-grant-hendry]

I believe there may be something wrong with the way it redraws a line when it needs to update it.

Without --ansi (13 lines total):
With --ansi (145 lines total):

That looks like verbose mode when --ansi is used...weird.

[MicaelJarniac]

Would this be different from setting ANSICON to a non-empty value?

I suppose this could do the trick. I still think FORCE_COLOR would be nice, but this might help. Thanks for the tip!

[MicaelJarniac]

That looks like verbose mode when --ansi is used...weird.

Do you happen to know if this has been fixed?