Poetry support

[AliGhahraei]

Hi!

Thank you for this great project. I just started using it, but it's been pretty useful so far. The only thing I've struggled with is figuring out how to make it work with poetry because if it just runs mypy normally, it can't find my installed libraries and I get many Cannot find implementation or library stub for module named "<module>". Right now I use a pylsp-mypy.cfg file with:

{"overrides": ["--python-executable", "<path-to-poetry-venv>/bin/python", True]}

This works, but I don't commit it because that venv path will be different for every device. If some kind of option to set the mypy executable existed, I could tell pylsp-mypy to run poetry run mypy, so do you think that feature or something similar could exist?

Sorry if we already have some way to configure this I don't know about and thank you again.

[Richardk2n]

I am afraid venv support will always a bit difficult to understand (especially with such venv management tools that like to hide what you are doing).

If mypy is present on PATH, that mypy is used. Otherwise, the mypy installed in the venv where pylsp-mypy is installed is used. You could just activate the venv which has the desired mypy installed. That is the most common way people do it. That should do the trick.

If this does not work for you for some reasons, I would need to know, what is installed in which venv (as in where is mypy where is pylsp-mypy where are the stups).

[petergaultney]

this is a different approach that would also work.

essentially, right now the 'command' for subprocess.run is "mypy", but if it were possible to configure this command (perhaps via the same pylsp-mypy.cfg file - though personally I'd prefer to set this config up in a place that does not require recreation every time I clone my shared repository that I can't clutter with config files related just to my usage) to be something different, e.g. ["poetry", "run", "mypy"] or ["pipenv", "run", "mypy"], then things would become a lot simpler for venv support, since most of these venv managers support running something inside the venv with a prefixed command of that sort.

One additional modification that would be necessary is to run the command with cwd=document.path.parent - because most of these venv managers can detect their venv only if the shell command is run at or below where the venv definition file (e.g. pyproject.toml) exists.

[squat]

One way to solve this without resorting to changing the Python executable or changing the mypy executable to which pylsp-mypy points is by launching your editor process inside of a shell that has your virtualenv bin path at the front of your `$PATH variable.

In poetry this is easy:

1. run poetry shell to activate your virtual environment; your virtualenv's bin path is now at the front of $PATH; then
2. run $EDITOR to launch your editor; when pylsp-mypy runs mypy, it will use the first mypy on your path, i.e. the one installed in your virtual environment.

[pinghedm]

Any way the closure of this issue could be revisted?

I also am having trouble getting use out of this with a virtual environment for my project. It runs a mypy not in my virtual env and so can not see my plugins and dependencies.

I could install my projects dependencies into the virtual environment that pylsp creates for itself on install, but that doesn't seem like it's really the right solution, to just pollute a global space with all my projects. I suppose I could adjust my path so that the mypy for the project that I'm working on at the moment is the first mypy found - this also isn't a great solution, any time I want to change projects

The pylint pylsp plugin has a configuration setting for pylint executabl` to solve the same problem in a clean way, as @petergaultney mentions above.

Is there a proper way to set this up that I just haven't found? Setting --python-executable in the pylsp_mypy.overrides did not fix things for me, the server then just fails to find my project dependencies

[petergaultney]

for what it worth, I've solved this with a fork of this repo.

I can't open my editor inside a shell with the venv active because I have hundreds of venvs.

I made the plugin perform a (cached) external request to find the correct command to use for running mypy.

anyone who is interested is welcome to take a look at my fork, and I'm happy to help you get it set up in your environment.

[Richardk2n]

@pinghedm You can install mypy in your project venv. Whenever you activate the venv to one of your projects this mypy is put into PATH and pylsp-mypy defaults to using it. This is a very convenient way to manage your venvs without requiring any settings.

If you prefer settings --python-executable should do the trick. This by the way does not need to be set via overrides but can be set in the mypy config file as well. If this does not work for you, please open an issue and I will have a closer look.

I do hesitate to implement yet another way to handle venvs as the plugin is already rather cluttered and there are already two ways to do what you want.

[rchl]

Whenever you activate the venv to one of your projects this mypy is put into PATH and pylsp-mypy defaults to using it.

I think this suggestion makes too strong assumption about how the editor works. It probably will work if you start a separate editor instance for each project but for editors that can run multiple projects in a single process instance it's not a viable solution since it would affect every open project.

I would say that there should exist a consistent way of specifying venv in pylsp that would automatically apply to all of its plugins also (or if not then a pyslp-mypy specific one like the existing pylsp.plugins.jedi.environment) but if your suggestion to set python-executable also works then that's probably fine too.

[Richardk2n]

I think this suggestion makes too strong assumption about how the editor works. It probably will work if you start a separate editor instance for each project but for editors that can run multiple projects in a single process instance it's not a viable solution since it would affect every open project.

Yes, you are correct, it would only work for one of the opened projects. I did not think about that.

I do not know if there are enough pylsp plugins, that depend on the environment to justify handling it centrally (maybe @ccordoba12 can answer that?).

To the best of my knowledge python-executable does work. The environment management could use a cleanup tho. And if there is some kind of standard other plugins follow, that pylsp-mypy does not conform to, I would gladly change to that. Having a uniform way of handling environments would probably reduce confusion a lot.

[ccordoba12]

I do not know if there are enough pylsp plugins, that depend on the environment to justify handling it centrally (maybe @ccordoba12 can answer that?).

Well, I think that's a good idea even if there are not many plugins that use it because it's simpler to inherit the setting from the server itself.

Having a uniform way of handling environments would probably reduce confusion a lot.

Agreed. Do you have time to implement that in the server?