Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a FORCE_COLOR variable? #502

Closed
henryiii opened this issue Oct 22, 2021 · 8 comments · Fixed by #524
Closed

Provide a FORCE_COLOR variable? #502

henryiii opened this issue Oct 22, 2021 · 8 comments · Fixed by #524

Comments

@henryiii
Copy link
Collaborator

henryiii commented Oct 22, 2021

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
Copy link
Collaborator

theacodes commented Oct 23, 2021 via email

@dhermes
Copy link
Collaborator

dhermes commented Oct 23, 2021

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

@henryiii
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator

cjolowicz commented Oct 23, 2021

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
Copy link
Collaborator Author

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

Yep, I did. I'm aware of the standard 1, 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
Copy link
Collaborator Author

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

4 participants