MYPY_FORCE_COLOR only colours output on Windows, not macOS/Ubuntu

[hugovk]

Bug Report

When using MYPY_FORCE_COLOR (or FORCE_COLOR with master) on GitHub Actions (which is not a tty), colour only shows up for Windows, and not for Ubuntu or macOS.

To Reproduce

Test with a worklflow something like this:

name: Test

on: [push, pull_request, workflow_dispatch]

env:
  MYPY_FORCE_COLOR: 1

jobs:
  build:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        python-version: [
          "3.7",
          "3.10",
        ]
        os: [
          windows-latest,
          macOS-latest,
          ubuntu-latest,
        ]

    steps:
      - uses: actions/checkout@v3

      - name: Set up Python ${{ matrix.python-version }}
        uses: actions/setup-python@v4
        with:
          python-version: ${{ matrix.python-version }}

      - name: Install dependencies
        run: |
          python -m pip install -U pip
          python -m pip install mypy

      - name: Test
        run: |
          mypy test.py

Expected Behavior

Colour output for all three operating systems.

Actual Behavior

Colour output only for Windows:

And not for Ubuntu:

Nor macOS:

For example: https://github.com/hugovk/test/actions/runs/3185917456

Your Environment

• Mypy version used: 0.982
• Mypy command-line flags: none
• Mypy configuration options from mypy.ini (and other config files): none
• Python version used: 3.7 and 3.10

[A5rocks]

On Debian, this seems to work fine for mypy main.py | head. Weird that it does not appear as such for GitHub Actions's Ubuntu, which should be similar enough.

[A5rocks]

Asked a friend since this seems weird to me. Supposedly, GHA doesn't provide TERM, which I suppose is required for curses.setupterm. It does seem that adding TERM fixes this, though.

https://github.com/A5rocks/repro-13817/commit/5f65e7d7b2d2c08ba7f5cc0c789c1b72825dfaf0

[stdedos]

It would be nice for mypy to explicitly note that somewhere here:

"""Note that, for ``FORCE_COLOR`` to work, there needs to be a suitable ``TERM`` in the enviroment!"""

mypy/mypy/util.py

Lines 511 to 516 in ff81a1c

	def should_force_color() -> bool:
	env_var = os.getenv("MYPY_FORCE_COLOR", os.getenv("FORCE_COLOR", "0"))
	try:
	return bool(int(env_var))
	except ValueError:
	return bool(env_var)

TERM=ansi would be the MWE for mypy

[A5rocks]

Maybe mypy should just warn if TERM is not present yet the user wants to force color?

Generally it seems like a bug for MYPY_FORCE_COLOR to not force the color. A user wouldn't be setting this if they didn't want color to be enabled. Maybe a fix like #7771 (comment) could be considered

[bluenote10]

I'm observing the same issue on Gitlab. As far as I can see should_force_color is not used correctly:

mypy/mypy/util.py

Lines 604 to 612 in 5fcca77

	if not should_force_color() and (not f_out.isatty() or not f_err.isatty()):
	self.dummy_term = True
	return
	if sys.platform == "win32":
	self.dummy_term = not self.initialize_win_colors()
	elif sys.platform == "emscripten":
	self.dummy_term = not self.initialize_vt100_colors()
	else:
	self.dummy_term = not self.initialize_unix_colors()

In my opinion when a user says "force color" it should be enabled no matter what. However, I suspect that the following happens when setting FORCE_COLOR or MYPY_FORCE_COLOR:

• In line 604 the not should_force_color() is False, i.e., it will skip over that branch.
• In line 612 there is yet another check not self.initialize_unix_colors() which may fail, resulting in setting self.dummy_term = True, meaning that colors get turned off despite being forced.