dmypy ignores flags and config file

[sehyun-hwang]

Bug Report

dmypy ignores flags and config file
#11396 (comment)

@sehyun-hwang This seems like a dmypy bug. It seems that dmypy ignores cli flags or config file flags in certain cases.

Here's a file structure:

$ tree .
.
├── a.py
├── b.py
└── mypy.ini

And mypy.ini contains the following:

[mypy]
strict = True

a.py and b.py both contain:

def foo(): pass

This way mypy a.py won't show errors but mypy --strict a.py will. When alternating between dmypy check a.py and dmypy check b.py, at some point dmypy stops showing strict output. For the same reason it might be forgetting the --output flag being set as well.

To Reproduce

With the file structure above,

Expected Behavior

--strict flag and other arguments should be applied.

Actual Behavior
--strict flag of the last command gets ignored.

root@f24a1f5cf5c6:/mnt# dmypy run -- --strict foo.py
Daemon started
foo.py:1: error: Function is missing a return type annotation
foo.py:1: note: Use "-> None" if function does not return a value
Found 1 error in 1 file (checked 25 source files)
root@f24a1f5cf5c6:/mnt# dmypy run -- --strict bar.py
bar.py:1: error: Function is missing a return type annotation
bar.py:1: note: Use "-> None" if function does not return a value
Found 1 error in 1 file (checked 1 source file)
root@f24a1f5cf5c6:/mnt# dmypy run -- --strict foo.py
Success: no issues found in 1 source file

Your Environment

• Mypy version used: Latest version hosted in pip
• Mypy command-line flags: --strict
• Mypy configuration options from mypy.ini (and other config files):
  strict = true or no config file
• Python version used: 3.10
• Operating system and version: Latest Python Docker image

[eliotwrobson]

Is there a workaround for this issue? I'd really like to use dmypy on a project I'm working on (as it will speed up our CI job considerably compared to mypy), but I need to be able to set options in a config file.

[dubreuia]

We have the same problem, first execution dmypy run -- --config-file mypy.ini uses the --config-file, but second run doesn't

[dubreuia]

Maybe a bug in the arg parsing: https://github.com/python/mypy/blob/master/mypy/dmypy/client.py#L256

[felixmeziere]

I have the same issue! Really a bummer in terms of productivity :/

[dubreuia]

Hello all 👋 ,

I've made some progress in understanding the problem. For us the problem is that between two git pulls the daemon checks only the changed files (I think that's normal behavior), but outputs lots of errors that there wasn't in the first run (not sure why, that's the problem) or errors that are not present when running mypy alone

How to reproduce (for me)

• Run dmypy run -- --config-file mypy.ini
  • Success: no issues found in 4051 source files
• Use git pull to get changes
• Run dmypy recheck
  • Found 102 errors in 16 files (checked 4051 source files)
  • (running mypy alone doesn't output errors)
  • (the problem is also present with using dmypy run -- --config-file mypy.ini again)

The problem

• Second run of dmypy fails with errors that are wrong
• Hypothesis: second run of dmypy doesn't use the context from the previous run for type information
  • (only uses the changed files in isolation, so there's a lot missing)

What I tried

• I thought the arg parsing was at fault, I debugged the code and I'm sure it is good
  • I think the problem is likely in the code of: fine_grained_increment_follow_imports (here) which is called on the second run and subsequent
• I also tried forcing dmypy to use all the files by using dmypy recheck --update <ALL THE ROOT FOLDERS>
  • But mypy crashes with IsADirectoryError: [Errno 21] Is a directory: 'apps' (doesn't support folders)
  • (I might try to add folder support, or recursively go through the folders to find the files)

I'm out of ideas, hope it helps one of you to have a look

Update

• I've tried all the variations of dmypy recheck --update <LIST OF FILES> and dmypy check <LIST OF FILES> and it doesn't help

[dubreuia]

Latest update

In the hopes this will help someone days of trial and errors and debugging: we found a workaround

The problem described above here (dmypy second run outputs errors that aren't present) is NOT present if dmypy uses a pre-build fine-grained cache

Solution:

1. mypy --cache-fine-grained --config-file mypy.ini
2. dmypy run -- --use-fine-grained-cache --config-file mypy.ini
3. (later runs of dmypy has no issues, even when git pull and stuff)

[felixmeziere]

Same problem here, really a problem as the errors in vscode are different than when running mypy