matangover/mypy-vscode

Does not work out of box: either "venv: no such file" or "Error: spawn venv ENOENT"

Zocker1999NET opened this issue ยท 14 comments

Have freshly installed this extension because MS's extension did not detect mypy properly.

But I get strange errors with venv I do not understand not see any settings to tweak around it.

With disabled "Run Using Active Interpreter" (default), following error appears:

[2] Check folder: /home/zocker/projects/entertainment-decider/server
[2] Received python path from Python extension: venv
[2] Running dmypy in folder /home/zocker/projects/entertainment-decider/server
/home/zocker/projects/entertainment-decider/server/venv/bin/dmypy --status-file /home/zocker/.config/Code/User/workspaceStorage/5c355c0f430bde2070c52c0e0a14dcaa/matangover.mypy/dmypy-9f254c8cd1b0c78ca11372bd6ed4fc39474e4ac0-148246.json run --log-file /home/zocker/.config/Code/User/workspaceStorage/5c355c0f430bde2070c52c0e0a14dcaa/matangover.mypy/dmypy-9f254c8cd1b0c78ca11372bd6ed4fc39474e4ac0.log -- . --show-column-numbers --no-error-summary --no-pretty --no-color-output --python-executable venv
[2] stdout:
Daemon started

[2] stderr:
mypy: Invalid python executable 'venv': No such file or directory

[2] Error running mypy in /home/zocker/projects/entertainment-decider/server: mypy failed with error: "mypy: Invalid python executable 'venv': No such file or directory". See Output panel for details.

With enabled "Run Using Active Interpreter" which is what I want (so the newer mypy 1.0 from the venv is used) following happens:

[1] Check folder: /home/zocker/projects/entertainment-decider/server
Activation complete
[1] Received python path from Python extension: venv
[1] Running dmypy in folder /home/zocker/projects/entertainment-decider/server
venv -m mypy.dmypy --status-file /home/zocker/.config/Code/User/workspaceStorage/5c355c0f430bde2070c52c0e0a14dcaa/matangover.mypy/dmypy-9f254c8cd1b0c78ca11372bd6ed4fc39474e4ac0-148246.json run --log-file /home/zocker/.config/Code/User/workspaceStorage/5c355c0f430bde2070c52c0e0a14dcaa/matangover.mypy/dmypy-9f254c8cd1b0c78ca11372bd6ed4fc39474e4ac0.log -- . --show-column-numbers --no-error-summary --no-pretty --no-color-output --python-executable venv
[1] Error running mypy in /home/zocker/projects/entertainment-decider/server: Error: spawn venv ENOENT

Both times, VSC was executed from a python venv and it was configured to use it.
The venv was freshly created.

System information:

  • Debian GNU/Linux testing/unstable
  • Python 3.11.1
  • Visual Studio Code 1.75.1

Somehow the extension is receiving the python path as "venv", even though that is supposed to be an absolute path to the venv. I wonder if there is something wrong with your configuration or maybe something has changed in Microsoft's python extension. Can you show a screenshot of your python interpreter selection? Run the command "Python: Select Interpreter" and what do you see there?

If you can give steps how to reproduce the issue that could help. Because on my machine I can't seem to reproduce this. Thanks!

Oh, by selecting "another" venv I fixed it while making the screenshot you requested. This is the screenshot:
image

The in blue highlighted variant Python 3.11.1 ('venv') was the preselected (and until yesterday probably working) venv I get when launching VSC as follows from shell:

cd projects/entertainment-decider/server
source venv/bin/activate
vsc  # alias for code .

I fixed it by selecting the starred variant Python 3.11.1 ('venv': venv), but I have no idea why. VSC seems to remember the correct venv when restarting it.

Thanks for following up. I'll try to see if I can reproduce it. In any case I could also produce a better error message in case the Python interpreter is not found

It happens to me constantly now. It seems that on extension start, the extension gets the venv directory from the Python extension instead of the Python binary path. Re-selecting the same interpreter fixes the issues as the correct path is used on the interpreter update. Reloading the window or restarting VSCode is enough to make the problem come back.

On extension load:

[1] Received python path from Python extension: /path/to/.direnv/python-3.9.16

On interpreter change:

[1] Received python path from Python extension: /path/to/.direnv/python-3.9.16/bin/python

Versions:

  • VSCode: 1.77.3
  • Mypy: v0.2.3
  • Python: v2023.6.1

Thanks for the report. It seems the Python extension changed their API in a buggy way... I have to look into this

@patrys could you please check if the attached version solves it for you? It's using the new API which is supposed to be less buggy. I couldn't reproduce the issue myself...

Here it is - unzip it and install it with the command Extensions: Install from VSIX
mypy-0.3.0.vsix.zip

@matangover gave it a try, it seems to work after forcibly reselecting the same interpreter:

Mypy extension activated, version 0.3.0
Registering listener for interpreter changed event
Waiting for Python extension to load
Python extension loaded
Listener registered
[1] Check folder: /Users/patrys/GitHub/saleor/saleor
Activation complete
[1] Received Python path from Python extension: /Users/patrys/GitHub/saleor/saleor/.direnv/python-3.9.16/bin/python
[1] Running dmypy in folder /Users/patrys/GitHub/saleor/saleor
/Users/patrys/GitHub/saleor/saleor/.direnv/python-3.9.16/bin/dmypy --status-file '/Users/patrys/Library/Application Support/Code/User/workspaceStorage/061602eef601c65501aa01ce31c7d68d/matangover.mypy/dmypy-e8698e39a789a2864fa24fa537ccf0bac5caac48-21394.json' run --log-file '/Users/patrys/Library/Application Support/Code/User/workspaceStorage/061602eef601c65501aa01ce31c7d68d/matangover.mypy/dmypy-e8698e39a789a2864fa24fa537ccf0bac5caac48.log' -- . --show-column-numbers --no-error-summary --no-pretty --no-color-output --python-executable /Users/patrys/GitHub/saleor/saleor/.direnv/python-3.9.16/bin/python
Active interpreter changed for resource: /Users/patrys/GitHub/saleor/saleor

Thanks for checking. So now it works for you even after you reload VSCode? Or you still have to re-select the same interpreter every time?

patrys commented

Sorry, I was not clear. I had to reselect the interpreter once, after that it seems to work across reloads and restarts.

Great. I will release it to everyone

I think I'm getting the same error and reselecting the interpreter does not fix it:

2023-07-11 09:01:17.355 [info] No interpreter found from setting mypy-type-checker.interpreter
2023-07-11 09:01:17.355 [info] Getting interpreter from ms-python.python extension for workspace /Users/underyx/r2c/app
2023-07-11 09:01:17.357 [info] Interpreter from ms-python.python extension for /Users/underyx/r2c/app: /Users/underyx/r2c/app/server/.venv/bin/python
2023-07-11 09:01:17.358 [info] Using cwd from `python.linting.cwd`.
2023-07-11 09:01:17.361 [info] Server run command: /Users/underyx/r2c/app/server/.venv/bin/python /Users/underyx/.vscode/extensions/ms-python.mypy-type-checker-2023.1.11911749/bundled/tool/lsp_server.py
2023-07-11 09:01:17.361 [info] Server: Start requested.
2023-07-11 09:01:17.449 [info] [Error - 9:01:17 AM] Mypy Type Checker client: couldn't create connection to server.
2023-07-11 09:01:17.449 [info] Launching server using command /Users/underyx/r2c/app/server/.venv/bin/python failed. Error: spawn /Users/underyx/r2c/app/server/.venv/bin/python ENOENT
2023-07-11 09:01:17.449 [error] Server: Start failed: Launching server using command /Users/underyx/r2c/app/server/.venv/bin/python failed. Error: spawn /Users/underyx/r2c/app/server/.venv/bin/python ENOENT

even though

(semgrep-app-py3.11) underyx@san app % /Users/underyx/r2c/app/server/.venv/bin/python --version
Python 3.11.0

This is using v2023.1.11921011 of ms-python.mypy-type-checker. Edit: which I now see is not this extension. Sorry about the noise!

Thanks for reporting. This doesn't seem like the same issue as reported above, because you are specifying the dmypyExecutable manually. But it is the same error message. So to debug your issue:

  1. Does the file /home/alexander/Technik/Development/advent_of_code_2023/bin/dmypy actually exist?
  2. If you run it from the Terminal, does it run without error?

The original issue reported above is now fixed and released. @Alexander-Wilms if you're still experiencing an issue please open a new issue thanks