Problem with mypy integration (unable to configure mypy build targets/scope)

[ilevkivskyi]

Environment data

• VS Code version: 1.33.1
• Extension version: 2019.4.12954
• OS and version: Mac OS 10.13.6
• Python version (& distribution if applicable, e.g. Anaconda): all versions
• Type of virtual environment used: venv
• Relevant/affected Python packages and their versions: mypy (all versions)

Expected behaviour

Scope of mypy build is configurable

Actual behaviour

It is great that Python extension for VS Code provides mypy support out of the box.

However, some of our (mypy) users complained that they are not able to use mypy daemon (a.k.a. dmypy) in Python VS Code extension. After some investigation it turns out that there is a problem on a deeper level with mypy integration: It looks like Python extension tries to pass name of the currently active file (the one that is being edited) to mypy executable.

For example, if a user edits a file ./foo/bar/baz.py and a user configured mypy executable as just mypy and mypy arguments as --allow-redefinition, then the extension will run a subprocess mypy --allow-redefinition ./foo/bar/baz.py.

This is however not at all how mypy works. Mypy is not really a linter and in most cases cannot just type-check given file in isolation. Mypy type-checks a project as a whole, in particular changing a signature of a function can cause type errors in callers in other modules.

A possible workaround that I found is to write a short script that swallows and ignores the file name passed to it, and makes a properly configured call to mypy. This however looks ugly IMO.

I think that instead of appending the current file name, the scope of mypy build should be configurable as just other arguments passed to mypy. By default this would be just repo/project root.

[ilevkivskyi]

It looks like this is a dependency for #1577

[karrtikr]

Closing this with the intent of moving discussion to issue #1577

[brettcannon]

And just to be clear as to why this is closed, re-running mypy on every file save would be an expensive operation, and so getting support for mypy's daemon process is the best way to make sure that the performance is acceptable to not have to worry about the overhead of potentially linting the entire code base and then ignoring the output for all files that are not open in the editor.