Provide a FORCE_COLOR variable?

[henryiii]

How would this feature be useful?

On GitHub Actions, getting nox to print out color is a bit painful. You have to remember to add a --forcecolor every invocation (I happen to have one that does a ton of nox calls).

Describe the solution you'd like

A new variable, either FORCE_COLOR, or NOX_FORCE_COLOR, something like that, could be added to imply --forcecolor. If both FORCE_COLOR and NO_COLOR were set, NO_COLOR would take precedence. From a quick search, tox does not have this, and pytest uses --color=yes/no/auto, also without an environment variable (FORCE_COLOR). MyPy secretly provides MYPY_FORCE_COLOR. So feel free to say no. :)

Describe alternatives you've considered

I would be very happy if nox simply used color output on GitHub Actions, not requiring any workaround. Though I think having a way to force color is still nice, though not as critical as NO_COLOR.

I also tried TERM=xterm-color, which was mentioned in python/mypy#7771, but that did not produce color output.

My suggestions to PRs ratio is not great right now, so I'll try to fix that in the near future! 😳

[theacodes]

I'm for it. Since there isn't a well-established environment variable for this, let's use `NOX_FORCE_COLOR`.

…

On Fri, Oct 22, 2021 at 3:38 PM Henry Schreiner ***@***.***> wrote: *How would this feature be useful?* On GitHub Actions, getting nox to print out color is a bit painful. You have to remember to add a --forcecolor every invocation (I happen to have one that does a ton of nox calls). *Describe the solution you'd like* A new variable, either FORCECOLOR, or NOXCOLOR, something like that, could be added to imply --forcecolor. If both FORCECOLOR and NOCOLOR were set, NOCOLOR would take precedence. From a quick search, tox does not have this, and pytest uses --color=yes/no/auto, also without an environment variable. MyPy secretly provides MYPY_FORCE_COLOR. So feel free to say no. :) *Describe alternatives you've considered* I would be very happy if nox simply used color output on GitHub Actions, not requiring any workaround. Though I think having a way to force color is still nice, though not as critical as NOCOLOR. I also tried TERM=xterm-color, which was mentioned in python/mypy#7771 <python/mypy#7771>, but that did not produce color output. My suggestions to PRs ratio is not great right now, so I'll try to fix that in the near future! 😳 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#502>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5I43GWOVX62ME3EA4AC3UIG4STANCNFSM5GRH5NRQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[dhermes]

Backing up a bit, let's talk this through:

• AFAIK, nox only uses colors when it detects the terminal can handle colors
• The nox check for colors combines checks for TTY + possibly checks for ${TERM}
• Running in GitHub Actions and most other CI providers will always set CI=true, which we can check for (https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables)

[henryiii]

If we automatically got colors on CI, that would be great. Though you might need to be careful that piping to a log would be colorized (which is not the end of the world, with NOCOLOR available too, and likely rare on CI which logs already). Better CI detection doesn't have to be exclude adding NOX_FORCE_COLOR, though :)

[henryiii]

TERM does not seem to be checked, at least I don't see it. Here's what Rich does: https://github.com/willmcgugan/rich/blob/3331f2a0072f8772de48ff89d139efb0c67583b5/rich/console.py#L753 I don't know if it automatically prints color in CI, though.

[cjolowicz]

I think you meant NO_COLOR and FORCE_COLOR, with an underscore?

Nox supports NO_COLOR, which has an informal standard at https://no-color.org.

FORCE_COLOR has some precedents (pytest, tox 4, PyPA build, colorama (planned), various stuff in Node.js). So does {APPLICATION}_FORCE_COLOR (mypy, Ansible), and there are lots of other forms (PY_COLORS, CLI_COLORS). Rich decided against supporting FORCE_COLOR.

Light preference for FORCE_COLOR from my side, because the main use case appears to be enabling color output on GA in a non-tool specific way, and it's more explicit than checking for CI.

Edit: added pytest, tox, colorama

[henryiii]

I think you meant NO_COLOR and FORCE_COLOR, with an underscore?

Yep, I did. I'm aware of the standard ¹, and I'd have NO_COLOR take priority over *FORCE_COLOR. I rather it had been some sort of COLOR=, where 0 was no color, and 1 was color or maybe even 1-4 depending on how much color (which is what plumbum does, though like Rich, not with envvars).

Footnotes

1. Though I probably should implement it in plumbum.colorlib, and haven't yet. :( Partially because I want to pull plumbum apart into submodules, and that also I haven't had time to do yet. ↩

[henryiii]

Not that Rich is a color support library, not an application, which is why. Do any of those libraries support both FORCE_COLOR and <app>_FORCE_COLOR? Setting FORCE_COLOR would probably turn on pytest color and nox color, while NOX_FORCE_COLOR would just colorize nox and not pytest. Personally, if you want color with an envvar, I'd think you'd want it everywhere, while if you just want it on nox but not the items nox is running, you can use the command line flag. Currently you'd have to set FORCE_COLOR and --forcecolor to get both to print in color. Not strongly recommending anything, really, just posing options and ideas.

[cjolowicz]

Not that Rich is a color support library, not an application, which is why.

That's also how I take it.

Do any of those libraries support both FORCE_COLOR and <app>_FORCE_COLOR?

• PyPA build only has FORCE_COLOR.
• pytest has FORCE_COLOR and PY_COLORS for historic reasons, but no PYTEST_FORCE_COLOR or such.
• tox 4 supports FORCE_COLOR and TOX_COLORED, because their option parser allows all options to be supplied from environment variables, and they have a --colored option.

Personally, if you want color with an envvar, I'd think you'd want it everywhere

+1