Fall back to FORCE_COLOR environment variable if MYPY_FORCE_COLOR is not present #13814
Conversation
This comment has been minimized.
This comment has been minimized.
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
| def should_force_color() -> bool: | ||
| return bool(int(os.getenv("MYPY_FORCE_COLOR", os.getenv("FORCE_COLOR", "0")))) |
There was a problem hiding this comment.
fyi, if FORCE_COLOR is used for a different purpose (e.g. a different python library), it could contain a string, and this would raise an error.
There was a problem hiding this comment.
Yeah, would be better to just check whether FORCE_COLOR exists, with any value (even 0!).
There was a problem hiding this comment.
(even 0!)
...Really? If somebody puts FORCE_COLOR: 0 in a GitHub Actions workflow, they expect it to force color??
There was a problem hiding this comment.
(even 0!)
...Really? If somebody puts
FORCE_COLOR: 0in a GitHub Actions workflow, they expect it to force color??
From a review of the Python projects @hugovk linked to in #13806 (comment), it looks like the answer is: yup! tox is the only project on that list that will treat FORCE_COLOR: 0 as indicating that the user does not want color.
There was a problem hiding this comment.
Thanks for flagging this @nnrepos!
There was a problem hiding this comment.
@AlexWaygood thanks, but this is not what i was talking about. i was talking about a possible ValueError in case the variable is not a number (e.g. False).
There was a problem hiding this comment.
...Really? If somebody puts
FORCE_COLOR: 0in a GitHub Actions workflow, they expect it to force color??
Yes, that's what NO_COLOR does! 😅
Command-line software which adds ANSI color to its output by default should check for a
NO_COLORenvironment variable that, when present and not an empty string (regardless of its value), prevents the addition of ANSI color.
Here's how pytest does it:
There was a problem hiding this comment.
@AlexWaygood thanks, but this is not what i was talking about. i was talking about a possible
ValueErrorin case the variable is not a number (e.g.False).
Yeah, I understood! #13853 means that you won't get a ValueError for FORCE_COLOR if you provide a value for that variable that can't be passed to the int() constructor. (It preserves the behaviour for MYPY_FORCE_COLOR that was present prior to this PR, however, since that's longstanding behaviour, and "fixing" it might be a breaking change in some ways.)
#13853 looks like it might be rejected, though, so this may be a moot point :)
Fixes #13806
This PR adds support for a FORCE_COLOR environment variable. If both MYPY_FORCE_COLOR and FORCE_COLOR are present, mypy will continue to use MYPY_FORCE_COLOR over FORCE_COLOR. However, if only FORCE_COLOR is set, mypy will use that environment variable in much the same way it currently uses MYPY_FORCE_COLOR.
MYPY_FORCE_COLOR appears to be undocumented and untested currently, so this PR doesn't add any tests. However, @hugovk has tested this change manually and using GitHub Actions, and reports that it appears to work as expected.