Neither NO_COLOR, nor --no-color is respected with FORCE_COLOR= present in the env #12405
Description
Description
I have FORCE_COLOR=1 set globally on GHA workflow level. I use the following command to retrieve some data from the JSON output:
$ FORCE_COLOR= NO_COLOR=1 python -X utf8 -u -I -m pip install --find-links=./dist --no-index yarl --force-reinstall --no-deps --only-binary=:all: --dry-run --report=- --quiet | jq --raw-output .install[].download_info.url | tee -a "${GITHUB_OUTPUT}"It doesn't break on Windows, but it errors out on *nix. I tested locally and turned out that pip doesn't react to setting an empty FORCE_COLOR= (which is likely coming from Rich), but it also doesn't respect NO_COLOR=1 or the --no-color CLI arg. This results in colored JSON mixed with ANSI codes being piped into the jq program which is unable to parse it as it's no longer valid with all the garbage in-between the visible bytes...
The hack that worked for me is unsetting the FORCE_COLOR var via a separate Bash command: aio-libs/yarl@f202823.
P.S. This may be related to Textualize/rich#2924, but looks like there's problems or an incorrect invocation on pip's side regardless.
Expected behavior
--no-color should and NO_COLOR=<non-empty-value> should take precedence over FORCE_COLOR= and not output anything.
pip version
Whatever GHA ships with their Pythons but also 23.2.1 on my laptop
Python version
3.7-3.12
OS
GHA's Ubuntu/macOS, but not Windows
How to Reproduce
https://github.com/aio-libs/yarl/actions/runs/6934150793/job/18862144526#step:6:24
Output
Doesn't matter really, it's colorized JSON in my case, what matters is that it contains ANSI when it shouldn't.
Code of Conduct
- I agree to follow the PSF Code of Conduct.