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?

[adam-grant-hendry]

I still think FORCE_COLOR would be nice

Agreed. I have no idea where the hell ANSI_COLOR came from. I’m wondering if it should be removed or if it is an environment variable used for a specific Windows terminal…? I’m guessing the author meant it to indicate “do you want to use ANSI colors”, but once again, they did not document this!

My bet is it can be removed (unless someone can tell me if it is an environment variable used for a particular terminal).

Regardless, how to use environment variables needs to be documented!

[adam-grant-hendry]

Do you happen to know if this has been fixed?

I don’t know specifically about things being printed verbosely (as it appears in this case), but we did see duplicate printing of messages in poetry-relax issue #59, which I linked back to poetry issue #3097, which was fixed in poetry 1.3.0