Thanks to visit codestin.com
Credit goes to github.com

Skip to content

MYPY_FORCE_COLOR only colours output on Windows, not macOS/Ubuntu #13817

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.

Sign up for GitHub

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

Jump to bottom
Open
hugovk opened this issue Oct 4, 2022 · 6 comments
Open

MYPY_FORCE_COLOR only colours output on Windows, not macOS/Ubuntu #13817

hugovk opened this issue Oct 4, 2022 · 6 comments
Labels
bug mypy got something wrong topic-configuration Configuration files and flags

Comments

@hugovk
Copy link
Member

hugovk commented Oct 4, 2022

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:

image

And not for Ubuntu:

image

Nor macOS:

image

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
@hugovk hugovk added the bug mypy got something wrong label Oct 4, 2022
@AlexWaygood AlexWaygood added the topic-configuration Configuration files and flags label Oct 4, 2022
@A5rocks
Copy link
Collaborator

A5rocks commented Oct 5, 2022 •
edited
Loading

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.

image

@A5rocks
Copy link
Collaborator

A5rocks commented Oct 5, 2022

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
Copy link
Contributor

stdedos commented Sep 21, 2023 •
edited
Loading

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
Copy link
Collaborator

A5rocks commented Sep 22, 2023

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

@ghost
Copy link

ghost commented Feb 13, 2024

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

EliahKagan added a commit to EliahKagan/GitPython that referenced this issue Mar 9, 2024
@EliahKagan
Colorize mypy output on CI for easier reading
aeacb00 
See:

- python/mypy#13815
- python/mypy#13817

This seems to be working in in all jobs *except* for the Python 3.7
and 3.8 jobs on macOS.
@bluenote10
Copy link
Contributor

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.

@bluenote10 bluenote10 mentioned this issue Feb 28, 2025
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug mypy got something wrong topic-configuration Configuration files and flags
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@stdedos @hugovk @bluenote10 @A5rocks @AlexWaygood