Unable to use virtualenv.

[dsully]

Because pylsp-mypy imports mypy.api in the context of python-lsp-server, if one is working in a virtualenv mypy is unable to type check properly.

Other linters such as flake8 work, as they are forking and inherit the environment properly.

Any objection to updating this to call mypy via subprocess.run() ?

[Richardk2n]

My only concern would be: Can this cause problems as in decreased speed or race conditions? If not I would happily merge a pull request. (In terms of writing it myself, could be a week or two until i have time)

It would be nice if you could link an example how other linters do it, because I would assume, that it is save to do something similar.

[dsully]

Given that mypy already needs to run on whole files and usually needs to scan entire directories I'm not too worried about the speed of a library call vs fork & exec.

https://github.com/dense-analysis/ale/blob/7d8fb2ba1716a744446b811fc278ecf30d4eb771/ale_linters/python/mypy.vim

Is an example.

[eddiebergman]

I would almost consider this essential personally, has there been any update?

Edit: For context, I'm using nvim and originally only had a single environment housing python-lsp-server and associated plugins, i.e pylsp-mypy, that I would use for all projects.

The easiest workaround was to switch to installing python-lsp-server into each virtual environment created and tell nvim-lsp to point to it dynamically. Here's my setup in case it helps others.

# ~/.zshrc

pyvenv () {
    python -m venv .venv
    source './.venv/bin/activate'

    # Install language server tools
    pip install pyls-flake8 mypy-ls 'python-lsp-server[rope, mccabe, pycodestyle, pydocstyle, yapf]'
}

-- ~/.config/nvim/lua/lsp.lua
-- Activates pylsp only if in a virtaul env

if os.getenv("VIRTUAL_ENV") ~= nil then
    lsp.pylsp.setup({
        cmd = { os.getenv('VIRTUAL_ENV')..'/bin/pylsp' },
        ...
    })    
end

[Richardk2n]

I currently have 0 time (currently writing my Master thesis). I will have a look at this when I'm done (might be december).

Please use the workaround until then. I agree, that this seems like something i should do and I most likely will, it just is a matter of time. Sorry for the delay.

[eddiebergman]

Hi @Richardk2n,

That's no problem, your thesis is more important :) If I manage to get some time I might look into fixing it myself, best of luck!

[jpneverwas]

Howdy folks, I'm slightly saddened by the collective suffering expressed here because (unless I've totally lost it) this has been a mostly solved problem upstream for a good minute now, at least for the basic use case described. Unfortunately, I've only just discovered this fork because python-lsp-server isn't yet part of my "carefully audited" (outdated) toolset. Anyway, #22 attempts to deal with it in a more general way, which some may find objectionable (though I'd be happy to bend to your will). Please check it out, if you dare. Thanks.

[dsully]

@jpneverwas - curious what you mean by "mostly solved problem upstream" ?

[jpneverwas]

Dan Sully @.***> writes:

@jpneverwas - curious what you mean by "mostly solved problem upstream" ?

Last I checked, the python-executable option still doesn't work for stubgen (with Python 3).

[meshy]

@dsully thank you for opening this issue, and working out that calling with subprocess might fix this. I've opened https://github.com/Richardk2n/pylsp-mypy/pull/23 to switch over to it, and can confirm that this fixes the issue for me.