Mypy "Linting Output" empty despite regular command reporting errors

[beeb]

Environment data

• VS Code version: 1.38.1
• Extension version (available under the Extensions sidebar): 2019.9.3491.1
• OS and version: Windows 10 Pro
• Python version (& distribution if applicable, e.g. Anaconda): Anaconda Python 3.7.3 or 3.6.9
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda (miniconda)
• Relevant/affected Python packages and their versions: mypy 0.720
• Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info How to update the language server to the latest stable version #3977): Jedi Enabled True

Expected behaviour

Output from the mypy command is displayed in the OUTPUT tab under the Python dropdown, and the contents is parsed to be shown in the Problems tab

Actual behaviour

OUTPUT tab shows the command being executed (twice actually), but the Linting Output - mypy is empty. Copy-pasting the exact mypy command shown in this tab to a command prompt prints some errors as expected.

Yesterday I thought I had solved the problem by completely uninstalling and reinstalling miniconda, creating the virtual env again, which solved the problem for a little while. Now the problem is back. Cannot get mypy to work with either the base miniconda env or my custom one.

Steps to reproduce:

1. Create virtual environment with version python=3.6 or python=3.7 using miniconda3 on Windows
2. Install mypy through pip install or conda install
3. Select this environment from the status bar
4. Open document with expected mypy errors
5. Display OUTPUT tab and select Python from the dropdown list
6. Observe the ##########Linting Output - mypy########## being empty

Logs

> ~\AppData\Local\Continuum\miniconda3\envs\smsl\python.exe -m black --line-length 120 --skip-string-normalization --diff --quiet c:\...\file.py.10dc09022f6774807dcf3aee42e24318.py
cwd: c:\...
> ~\AppData\Local\Continuum\miniconda3\envs\smsl\python.exe -m black --line-length 120 --skip-string-normalization --diff --quiet c:\...\file.py.10dc09022f6774807dcf3aee42e24318.py
cwd: c:\...
> ~\AppData\Local\Continuum\miniconda3\envs\smsl\python.exe -m flake8 --max-line-length=120 --exclude=__init__.py --format=%(row)d,%(col)d,%(code).1s,%(code)s:%(text)s c:\...\file.py
cwd: c:\...
> ~\AppData\Local\Continuum\miniconda3\envs\smsl\python.exe -m flake8 --max-line-length=120 --exclude=__init__.py --format=%(row)d,%(col)d,%(code).1s,%(code)s:%(text)s c:\...\file.py
cwd: c:\...
> ~\AppData\Local\Continuum\miniconda3\envs\smsl\python.exe -m mypy --ignore-missing-imports c:\...\file.py
cwd: c:\...
> ~\AppData\Local\Continuum\miniconda3\envs\smsl\python.exe -m mypy --ignore-missing-imports c:\...\file.py
cwd: c:\...
##########Linting Output - mypy##########
##########Linting Output - flake8##########
53,1,D,D102:Missing docstring in public method
200,1,D,D102:Missing docstring in public method
234,1,D,D102:Missing docstring in public method

This is what the same command outputs if I run it in a separate terminal

(smsl) C:\Users\...>C:\Users\...\AppData\Local\Continuum\miniconda3\envs\smsl\python.exe -m mypy --ignore-missing-imports file.py
file.py:18: error: Module 'utilities.generic_utilities' has no attribute 'Config'

[karrtikr]

Hi @beeb 👋 Unfortunately, i am not able to reproduce it.

> ~\AppData\Local\Continuum\miniconda3\python.exe -m mypy --ignore-missing-imports --follow-imports=silent --show-column-numbers c:\Users\karraj\Desktop\yo\yo.py
cwd: c:\Users\karraj\Desktop\yo
> ~\AppData\Local\Continuum\miniconda3\python.exe -m mypy --ignore-missing-imports --follow-imports=silent --show-column-numbers c:\Users\karraj\Desktop\yo\yo.py
cwd: c:\Users\karraj\Desktop\yo
##########Linting Output - mypy##########
yo.py:6:10: error: Argument 1 to "greeting" has incompatible type "int"; expected "str"
yo.py:8:10: error: Argument 1 to "greeting" has incompatible type "bytes"; expected "str"

Contents of yo.py

def greeting(name: str) -> str:
    return 'Hello ' + name


# Argument 1 to "greeting" has incompatible type "int"; expected "str"
greeting(3)
# Argument 1 to "greeting" has incompatible type "bytes"; expected "str"
greeting(b'Alice')

Does it happen with other interpreters as well, with any file content?

[beeb]

Hey @karrtikr .
I also found that this bug is not always reproducible. My colleague which uses roughly the same environment did not have the issue as of recently.

At the moment it happens with any file content and any of the interpreters I have on my machine (which are all from conda environments).

Is there a way to see more in-depth debug logs that could hint at an issue? How could I investigate what happens during that process? Cheers

[karrtikr]

Is there a way to see more in-depth debug logs that could hint at an issue? How could I investigate what happens during that process? Cheers

Check and paste this mentioned in the issue template, see if you can find any errors.

Output from `Console` under the `Developer Tools` panel (toggle Developer Tools on under `Help`; turn on source maps to make any tracebacks be useful by running `Enable source map support for extension debugging`)

You could try debugging the extension code if you're really into investigating. This is where the output is being printed src\client\linters\baseLinter.ts#L190 . You can find the instructions in the contributing guide.

[beeb]

I on purpose did not include the console output because there was nothing more than in the output tab. Thanks for the hint, I'll try to investigate

[iutlu]

I believe I may be running into the same issue: Using Windows 10 with mypy installed into the workspace's (mini)conda environment, the problems panel shows nothing on source files with type errors. The output panel indicates that ~\Miniconda3\envs\myenv\python.exe -m mypy --ignore-missing-imports --follow-imports=silent --show-column-numbers c:\Users\iutlu\Desktop\foo\bar.py has been executed, but without any kind of output (related: #5850). Running the same command in the built-in (activated) terminal does report the type errors, as expected.

I've spent some time tinkering around, and managed to get a traceback out of vscode by replacing python.linting.mypyPath with a dummy python script that calls mypy via subprocess.

Traceback (most recent call last):
  File "C:\Users\iutlu\Miniconda3\envs\myenv\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Users\iutlu\Miniconda3\envs\myenv\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Users\iutlu\Miniconda3\envs\myenv\lib\site-packages\mypy\__main__.py", line 4, in <module>
    from mypy.main import main
  File "C:\Users\iutlu\Miniconda3\envs\myenv\lib\site-packages\mypy\main.py", line 12, in <module>
    from mypy import build
  File "C:\Users\iutlu\Miniconda3\envs\myenv\lib\site-packages\mypy\build.py", line 58, in <module>
    from mypy.metastore import MetadataStore, FilesystemMetadataStore, SqliteMetadataStore
  File "C:\Users\iutlu\Miniconda3\envs\myenv\lib\site-packages\mypy\metastore.py", line 12, in <module>
    import sqlite3
  File "C:\Users\iutlu\Miniconda3\envs\myenv\lib\sqlite3\__init__.py", line 23, in <module>
    from sqlite3.dbapi2 import *
  File "C:\Users\iutlu\Miniconda3\envs\myenv\lib\sqlite3\dbapi2.py", line 27, in <module>
    from _sqlite3 import *
ImportError: DLL load failed: The specified module could not be found.

It looks like the mypy module fails to run due to an import error from sqlite3, which is weird since this would indicate something is just wrong with the Python environment. So I thought this was maybe some conda issue, and yes indeed, it was:

Essentially, running ~\Miniconda3\envs\myenv\python.exe -m mypy --ignore-missing-imports --follow-imports=silent --show-column-numbers c:\Users\iutlu\Desktop\foo\bar.py in an unactivated terminal produces the error, while an activated environment works OK.

This is quite surprising to me, I would've thought that using the full path to the conda env's python executable (as VSCode seems to be doing) would just work. Apparently, what is needed is to spawn a shell process, run the conda activate script, and then launch mypy from there. I don't understand Python's import mechanics well enough to understand why this is going on, but maybe the VSCode Python extension should try to run the linters through an activated environment, as well?

So possible workarounds are:

1. Use a small script for python.linting.mypyPath that patches os.environ['PATH'] with the PATH of an activated environment, then runs mypy
2. Use the mypy package from conda-forge (as opposed to the default anaconda channel). That package doesn't appear to require an activated env to work. Maybe it's a version issue (0.74 on conda-forge vs 0.72 on anaconda), or maybe there's something wrong with the way mypy from the anaconda channel is packaged.

[kimadeline]

Hi @iutlu, thank you for posting your workarounds 👍 @beeb do they work for you?

As for your suggestion @iutlu (run the linters through an activated environment), it is being tracked and worked on right here (I'm on it 👋): #7696

Thanks!

[beeb]

I'll report back later today, thanks for the in-depth write-up. Hold tight!

[beeb]

Well guys, it seems today I'm not able to reproduce the bug I had. Mypy is working as expected even without any workaround ¯\(ツ)/¯
I really don't know what was up at the time. If I ever encounter the problem again I'll try to report.

[kimadeline]

Alright, I'll close this issue for now, and if anybody encounters it again (and the suggested workarounds don't work) feel free to comment here and I'll reopen it 🙂

[karrtikr]

@beeb We recently closed #5326. Maybe your issue was related to it.

[beeb]

Thanks @karrtikr but it isn't. I found that issue when I was looking up my problem but it was unrelated to filename, as I used very simple names when testing.

[iutlu]

@kimadeline great to see this is being fixed! @beeb interesting -- possibly I'm facing a different issue than the original 😕 @karrtikr I was also not using any nonstandard names (foo, bar in fact 😄)

[kimadeline]

According to https://twitter.com/jeremytwfortune/status/1467866142849081351, it can be caused by multiple layers of .mypy_cache folders within the workspace, and removing all instances of the cache folders fixes it.