search

python-lsp / pylsp-mypy

Mypy plugin for the Python LSP Server.
MIT License
127 stars 35 forks source link

Using virtualenv in emacs/python-lsp-server may not work when using pipx. #26

Closed sathlan closed 2 years ago

sathlan commented 2 years ago

Hi,

thanks to #17 it's more straightforward to use this plugin in virtualenv. It's still not working for my case though:

  1. Install python-lsp-server using pipx and inject pylsp-mypy in that env: only pylsp is in the PATH

    ~/.local/bin/pylsp -> ~/.local/pipx/venvs/python-lsp-server/bin/pylsp

  2. go to your python project and activate it: mypy is still not in the PATH, only python and whatever python binaries your project install.

  3. have mypy installed in some other way on your system so that it's in your PATH.

Now when your editing python file in your project, mypy will be run from the system installation (3.) and won't find any of the module in your virtual env:

Screenshot from 2021-12-14 13-54-57

On the emacs console pylsp::stderr this gives:

2021-12-14 14:00:57,792 CET - INFO - pylsp_mypy.plugin - executing mypy args = ['--show-column-numbers', '~/src/personal/rh-dtl/dtl/dtl.py', '--incremental', '--follow-imports', 'silent']
2021-12-14 14:00:58,244 CET - DEBUG - pylsp_mypy.plugin - report:
dtl/dtl.py:5:1: error: Cannot find implementation or library stub for module named "htmllistparse"
dtl/dtl.py:5:1: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
dtl/dtl.py:8:1: error: Library stubs not installed for "requests" (or incompatible with Python 3.10)
dtl/dtl.py:8:1: note: Hint: "python3 -m pip install types-requests"
dtl/dtl.py:8:1: note: (or run "mypy --install-types" to install all missing stub packages)

The problem is that I'm using the mypy binary from the system which know nothing about the virtualenv of that particular project.

All other part of the python-lsp-server are working fine and do see the library in the venv:

Screenshot from 2021-12-14 14-18-58

Richardk2n commented 2 years ago

The changes related to #17 dictate, that the mypy of the currently active env are used. If no venv is active your system python is your currently active env. This is sensible. This leads to an issue when using a env in which no mypy is installed. However, up until now, the "expected" behavior would be a crash. If it does not crash it appears to fall back to another mypy, which as far as i can tell has no business being on your part at that point. Therefore in the newest release if no mypy is on the path, the code falls back to the mypy installed as a dependency, this might work for you if there is no mypy to fall back to. Could you please test if this works for you?

Richardk2n commented 2 years ago

Closing as no response is interpreted as the issue is fixed