python-lsp / pylsp-mypy

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

Two invocations of dmypy made and appear to invalidate the cache #44

Closed tyoung-patreon closed 1 year ago

tyoung-patreon commented 1 year ago

I'm using pylsp-mypy with neovim native lsp in dmypy mode, and when I save a file I don't get any of the speedup from using dmypy, so it takes 10s of seconds for type checking to load. When I use dmypy on the command line individually it runs instantaneously after edits (outside of neovim). If I edit within neovim (and therefore run dmypy through this plugin), then the mypy cache appears to get entirely recalculated and no caching happens.

local lsp = require('lspconfig')
local util = require('lspconfig.util')
lsp.pylsp.setup({
  settings = {
    pylsp = {
      plugins = {
        pylsp_mypy = {
          live_mode = false,
          enabled = true,
          dmypy = true,
        },
      }
    },
  },
  root_dir = function(fname)
    local root_files = {
      'requirements.txt',
    }
    return util.root_pattern(unpack(root_files))(fname) or util.find_git_ancestor(fname)
  end,
})

After editing a file and running ps aux | grep mypy I get two identical looking commands as output:

.direnv/python-3.7.15/bin/python3.7 .direnv/python-3.7.15/bin/dmypy run -- --show-column-numbers <file>
❯ pip freeze | grep -E '(lsp|mypy)'
mypy==0.931
mypy-extensions==0.4.3
mypy-protobuf==3.2.0
pylsp-mypy==0.6.3
pylsp-rope==0.1.10
python-lsp-black==1.2.1
python-lsp-jsonrpc==1.0.0
python-lsp-server==1.5.0
tyoung-patreon commented 1 year ago

One duplicate value I see in the debug logs of the LSP server is:

[DEBUG][2022-10-26 17:37:28] .../vim/lsp/rpc.lua:285    "rpc.send"  {  jsonrpc = "2.0",  method = "workspace/didChangeConfiguration",  params = {    settings = {      pylsp = {        plugins = {          pylsp_mypy = {            dmypy = true,            enabled = true,            live_mode = false          }        }      }    }  }}
[DEBUG][2022-10-26 17:37:28] .../vim/lsp/rpc.lua:285    "rpc.send"  {  jsonrpc = "2.0",  method = "workspace/didChangeConfiguration",  params = {    settings = {      pylsp = {        plugins = {          pylsp_mypy = {            dmypy = true,            enabled = true,            live_mode = false          }        }      }    }  }}

On save it just has the following:

[DEBUG][2022-10-26 17:45:53] .../vim/lsp/rpc.lua:285    "rpc.send"  {  jsonrpc = "2.0",  method = "textDocument/didSave",  ....
[ERROR][2022-10-26 17:45:53] .../vim/lsp/rpc.lua:733    "rpc"   "pylsp" "stderr"    "Daemon has died\n"

And that is when two dmypy instances are invoked, so I'm not sure why that would be happening. It looks like only a single "didSave" rpc is sent, but perhaps two receivers are set up a the beginning? There's only a single instance of pylsp running.

I also don't know what the "Daemon has died" is from, any ideas?

tyoung-patreon commented 1 year ago

Additionally it looks like when I run dmypy start beforehand that server instance is killed by the newly created invocations. Only one of them is left in .dmypy.json and when I run dmypy status it outputs Daemon is stuck;

tyoung-patreon commented 1 year ago

Looking into the code more it looks like a few things are going wrong. It could be that my dmypy version is off from what this codebase expects (if so my bad).

It should probably status check using dmypy status instead of just "dmypy", *apply_overrides. I think because the existing dmypy is created with run it then kills that daemon and starts a new one. I'll see if I can make a reasonable PR to fix this if it isn't intended behavior.

Richardk2n commented 1 year ago

I know it gets invoked a more often than it should, but did not have the time to figure out why. Thank you for investigating. Did you test if this PR fixes your problem?