Closed FelisNivalis closed 1 year ago
When mypy exists on path it is used. This is to assure that common venv use cases work. Therefore, this is intended behavior. mypy should not exist on PATH if you do not intent to use it.
I understand that. The issue here is that pyenv
works in a way that all executables in ALL environments are put in a shims
folder so only checking whether mypy
is on PATH does not ensure mypy
exists in the current virtual env.
I think it would be better either to check mypy
exists on the corresponding bin
path of VIRTUAL_ENV
, or make extra checks for pyenv
.
This kind of sounds like pyenv purposely puts broken executables at the front of PATH. I would not encourage changing the checking for venvs as it already is pretty confusing and writing code dependent on venv directory structure might break things (and it might not be applicable to the system-wide installation).
In terms of extra check for pyenv, that might be ok, but I am not too keen on doing it. If you can write a PR that does this without too much clutter I am willing to merge it.
An easy workaround for you would be installing mypy in your active venv.
I'm using
pylsp-mypy
withcoc.nvim
and havepyenv
installed. When linting,pylsp-mypy
detectsmypy
is on path and tries to execute it, but it's only installed on one of mypyenv
venvs, so it fails with