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

Neither NO_COLOR, nor --no-color is respected with FORCE_COLOR= present in the env #12405

Open
1 task done
webknjaz opened this issue Nov 20, 2023 · 2 comments
Open
1 task done
Labels
S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior

Comments

@webknjaz
Copy link
Member

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

@webknjaz webknjaz added type: bug A confirmed bug or unintended behavior S: needs triage Issues/PRs that need to be triaged labels Nov 20, 2023
webknjaz referenced this issue in aio-libs/yarl Nov 20, 2023
This is a hack to work around the inability of `Rich` -- and by
extension `pip` -- to allow overriding a `FORCE_COLOR` environment
variable, made available globally.

The following **doesn't** actually work:

    $ NO_COLOR=1 FORCE_COLOR= python -m pip install yarl --no-color --dry-run --no-deps --report - --quiet | jq --raw-output .install[].download_info.url

Ref: Textualize/rich#2622
@webknjaz
Copy link
Member Author

UPD: Apparently, NO_COLOR=1 does disable coloring but keeps other ANSI escape codes that Rich generates. There's a bit of dissonance between the interpretation of FORCE_COLOR and NO_COLOR. So the latter only partially cancels out the effect of the former: Textualize/rich#2449 (comment).

@webknjaz
Copy link
Member Author

I started discussions on the trackers of the corresponding standards: https://github.com/jcs/no_color/issues/267 / donatj/force-color.org#8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

No branches or pull requests

2 participants
@webknjaz and others