Description
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.