mypy failing with invalid filenames

[AntonioL]

Environment data

• VS Code version: 1.30.2
• Extension version (available under the Extensions sidebar): 2019.1.0
• OS and version: Mac OS X Mojave
• Python version (& distribution if applicable, e.g. Anaconda): 3.7.2
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): pipenv

Expected behaviour

Have a virtualenv set up through pipenv.

I installed the following packages in my virtual env (obtained via pipenv run pip freeze :

astroid==2.2.5
attrs==19.1.0
isort==4.3.17
lazy-object-proxy==1.3.1
mccabe==0.6.1
mypy==0.700
mypy-extensions==0.4.1
pylint==2.3.1
rope==0.14.0
six==1.12.0
typed-ast==1.3.1
wrapt==1.11.1

I have the following settings:

{
    "python.pythonPath": "/Users/alombardo10/.local/share/virtualenvs/feeds-file-retrieval-riYOLLaH/bin/python",
    "python.linting.enabled": true,
    "python.linting.pylintEnabled": true,
    "python.linting.mypyEnabled": true
}

Actual behaviour

I am deliberately adding type errors

def ciao(a : int) -> None:
    ()

ciao("aaa")

But nothing is reported under Problems for this project, I have another project with similar setup and it works.

I am running via cmdline mypy via pipenv and it definitely catches those.

My suspicion is that it is not calling mypy at all.

Steps to reproduce:

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

##########Linting Output - mypy##########
##########Linting Output - pylint##########

--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

[ericsnowcurrently]

Hi @AntonioL. Thanks for letting us know about this problem. Unfortunately I have not been able to reproduce the problem. I switched to a folder that has pipenv set up, set the interpreter environment to the local pipenv one, and enabled mypy in my settings. The extension prompted me to install mypy, which it did via pipenv. After that, I started getting the mypy messages in my "Problems" pane, as expected.

So I'm not sure what the problem might be. If you didn't have mypy installed then the extension would prompt you to install it. If you did have it installed then you would see the errors. Here are a couple of things to check:

• what happens if you use a different version of mypy (e.g. don't pin it, just use "*")?
• do you have any special mypy config?
• do you get "Problems" messages from pylint (e.g. if you put a syntax error on a line)?

Thanks!

[AntonioL]

1. Keep in mind that I pulled last version of mypy. I am using pipenv here, so there is no pinning, the above output is coming from pip freeze.
2. Nope
3. Yes, I do see pylint errors.

Also I want to stress that:

But nothing is reported under Problems for this project, I have another project with similar setup and it works.

Actually the issue seems to be specific to this project, but cannot troubleshoot further.
I will just try hinting one potential cause, might be some file path related issue?

I remember I had tried to recreate the pipenv environment and the issue did not go away.

[jwickens]

I have the same issue. I run mypy manually in the conda env and I see the problems I expect, but nothing is shown in editor, under problems or under mypy output:

VS Code version: 1.33.1
Extension version (available under the Extensions sidebar): 2019.4.11987
OS and version: Mac OS X Mojave
Python version (& distribution if applicable, e.g. Anaconda): 3.7.3
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda

[guillemglez]

Same problem here. The .mypy_cache folder is generated, but no result is shown in problems tab neither in the editor, so looks like the issue has something to do with VSCode being unable to retrieve its results...

VS Code version: 1.33.1
Extension version (available under the Extensions sidebar): 2019.4.2
OS: Windows 10
Python version: 3.68
Type of virtual environment used: conda
mypy version: 0.701

[yxliang01]

The raw output from linter is not logged, making debugging this difficult. I am suspecting it's something wrong with the REGEX defined. @ericsnowcurrently did you try to reproduce with latest version of mypy?

[harpaj]

I had the same problem and it actually turned out to be a mypy issue that was completely silenced (which I think is the actual problem here - the mypy error is not shown in vs code).

To figure out what's going wrong you can do the following (works on Linux and probably Mac, I don't know enough about Windows unfortunately):

1. Create, somewhere on your PC, a file with the following content:

#!/bin/sh
echo $@ >> /home/my_user/some_path/mypy_call.log

2. Make that file exectuable
3. Enter the full path to the file as the "mypy path" in VS Code
4. Use VS Code so that it lints a file which should create some mypy error.
5. Open mypy_call.log. You should see in each line the exact arguments VS Code is passing to Mypy.
6. Call mypy with these arguments. Most likely, you'll get some error, which you can fix then.
7. Don't forget to change back your mypy path.

[yxliang01]

@harpaj That's a good idea. I don;t have the environment setup now. Could you share the log you got? Maybe it gives us hints. Thanks

[yxliang01]

@harpaj Thanks for your idea. Indeed, letting it print the calling arguments and reproduce without the extension is a good and easy thing to do - I was only thinking that the extension didn't even execute mypy due to empty output. For my case, it was that the full path of the files contains illegal character for being a package name which prevents mypy from running successfully. And, indeed, the output window didn't show mypy's error message for some reason.

FYI also, you can just change the mypy path to /bin/echo (or other paths to echo, depending on your operating system) without creating a new script or log file. In the output window, you can see the invoking arguments.

[harpaj]

Happy I could help!
Using /bin/echo is a clever way of avoiding the bash script, thanks for that! And using illegal characters in the full path appears to be a good minimum example of reproducing the error.
@ericsnowcurrently, does this provide you with enough information to reproduce?
So, the title of the issue should rather be something like mypy failures are not shown, since no actual linting output is produced.

On a side note, to avoid such issues in the first and make mypy behave the same when being executed from VS code and externally, it might be a good idea to invoke mypy from the working directory and passing the relative path instead of the full path to it (no idea if that's possible).

[yxliang01]

@harpaj I've just created a script for having the described behaviour. https://gist.github.com/yxliang01/b975fffa0b145d75ed1dba5b3a9ad960 Works well for me. But, in long term, I think the modification should be done in this codebase. Maybe we can create a new issue for changing this behaviour (execute with relative path)? I've just read the code. It's definitely possible (with potentially very few changes required).

[yxliang01]

Anyways, just created PR #5834 which enforces the behaviour described in #5326 (comment) .

[ericsnowcurrently]

@harpaj, @yxliang01, thanks for figuring this out. So, if I understood correctly, the following should happen:

• write error output from mypy to the test output pane
• use relative paths when invoking mypy (a la PR fix(client/linters/mypy): call mypy incorrectly #5834)
• quote the filename passed to mypy?

I've opened issue #5850 for the first item. We'll keep the rest on this issue (I've updated the title). If there is anything else that needs to be done, please open a separate issue (to keep things nice and granular).

[yxliang01]

@ericsnowcurrently Nice! But, would you like to clarify item 3? Why quoting is required?

[karrtikr]

@yxliang01 @harpaj @AntonioL It's no longer reproducible for me, so I think the issue is fixed, closing this now. If it's not, please let us know and we can reopen it.