[REQUEST] Respect PY_COLORS environment variable

PY_COLORS is a very popular method for forcing ANSI mode on or off in a command line application.

Basically undefined means keeping application default behavior, likely auto-detection. Having it PY_COLORS=0 means application will not use any ANSI codes and PY_COLORS=1 will force ANSI mode regardless if terminal reports it or not.

For me personally is not a big deal as I already have code in applications I work with, but it would prove useful to have this directly into rich, so any user of rich would get this for free.

An implementation example can be seen at https://github.com/ansible-community/molecule/blob/20e1fa8a23308a9103e2dbdb4d3c4ae1ffe59c9d/molecule/logger.py#L42-L48

That is very useful feature to have when running on CI as you do not want to end-up defining 50-100 environment variables only to control ANSI behavior.

[willmcgugan]

They not really standards, since they’re not documented by any kind of authority. And not all that established, since relatively few apps support them.

They’re also implemented inconsistently, for instance on some apps FORCE_COLOR=0 would force color on because anything other than empty string is considered True, but some apps would treat “0” as false and disable color. And if I implement more than one, what if they conflict?

If I was to add support for these env vars, then I’ve baked that in to all apps using Rich, which means that if I change it in the future when / if a standard emerges @willmcgugan is going to get a lot of angry mentions.

So I’d rather to leave it up to the developer what env vars they should support. It’s only a line or two to set force_color on the Console constructor.

I may yet relent on this. I try to be pragmatic!

[ewels]

Yes, for future googlers wanting to copy and paste, here was my workaround to do the same with our codebase: https://github.com/nf-core/tools/pull/760/files (bit simpler / more crude, includes direct detection for GitHub Actions).