Reload of LSP buggy

[HallerPatrick]

When reloading the lsp(s), the Pyright server is not getting started again

[jonesmartins]

When I reopened Nvim, Pyright never recognized the venv's packages. I added event="BufRead" to py_lsp's setup in Packer. Something along the lines of

use { 
   'HallerPatrick/py_lsp.nvim',
    event = 'BufRead',
    config = function()
      require('py_lsp').setup()
    end
},

I'm not sure if it's the correct event to use, but it fixed the issue (for now?).

[HallerPatrick]

Hey! The lookup algorithm for finding the venv's is not good yet. Maybe some questions to solve this problem:

1. Where is your venv located?
2. And from where do you start neovim?
3. What is the working directory? (command is :pwd)

Greetings!

[jonesmartins]

Hi, Patrick!

I created a project through Poetry by running poetry new <package> inside <package>'s parent directory.

1. Having the .venv directory be inside my package's directory is not a default setting. I had to run poetry config virtualenvs.in-project true to ensure Poetry always creates a virtual environment locally, instead of at {cache-dir}/virtualenvs, which is somewhere by the home directory.

Here's my project's tree structure:

<package>
├── <package>
├── .mypy_cache
├── __pycache__
├── .pytest_cache
├── tests
└── .venv 

2. I started Neovim from inside <package>'s directory by running nvim ..
3. Running :pwd from inside Neovim returned <package>'s absolute path, which was expected.

I'm running Ubuntu 20.04 in case that's important.

[HallerPatrick]

The step of generating the poetry venv inside the package is not needed. py_lsp is able to figure the location out by itself.

Does the command poetry env info -p give you the location of your venv? Also maybe try a :LspRestart is neovim to see if something pops up...

[jonesmartins]

I generated a venv inside my package on purpose to ensure that my project's dependencies were independent of system Python's dependencies, much like node_modules works for Javascript.

Does the command poetry env info -p give you the location of your venv?

Yes, it's at <path_of_package>/.venv/

Also maybe try a :LspRestart is neovim to see if something pops up...

Okay, this is interesting, and different from what I got before. Let's assume that this is the real test.

I opened Neovim with nvim ., selected some file, and Pyright didn't recognize my imports. I ran :LspRestart and nothing happened. Then I moved my cursor, and I was notified Py_Lsp found a .venv local directory. I assume that's BufRead's fault?

Anyway. I tested :LspRestart again by running nvim <some_file.py>. Pyright, again, failed. I ran :LspRestart, waited a little, moved by cursor, and nothing changed.

So, I removed event = "BufRead". I'm not sure it's doing anything, but just to be safe.

After a bit of back and forth, I concluded that it's something related to py_lsp's package loading. Sometimes it worked after running :PackerSync, sometimes after running :PackerCompile.

We'd need to test this in a fresh install of Nvim to make sure it's not related to other packages.

[HallerPatrick]

I generated a venv inside my package on purpose to ensure that my project's dependencies were independent of system Python's dependencies, much like node_modules works for Javascript.

Poetry also handles the dependency of your project independently, even if it is not in your project. So using virtualenvs.in-project will not make a difference regarding dependency resolution.

Does the command poetry env info -p give you the location of your venv?

Yes, it's at <path_of_package>/.venv/

Also maybe try a :LspRestart is neovim to see if something pops up...

Okay, this is interesting, and different from what I got before. Let's assume that this is the real test.

I opened Neovim with nvim ., selected some file, and Pyright didn't recognize my imports. I ran :LspRestart and nothing happened. Then I moved my cursor, and I was notified Py_Lsp found a .venv local directory. I assume that's BufRead's fault?

Anyway. I tested :LspRestart again by running nvim <some_file.py>. Pyright, again, failed. I ran :LspRestart, waited a little, moved by cursor, and nothing changed.

So, I removed event = "BufRead". I'm not sure it's doing anything, but just to be safe.

event = "BufRead" does not change the behaviour in my tests

After a bit of back and forth, I concluded that it's something related to py_lsp's package loading. Sometimes it worked after running :PackerSync, sometimes after running :PackerCompile.

We'd need to test this in a fresh install of Nvim to make sure it's not related to other packages.

I just now tried your configs with :

use { 
   'HallerPatrick/py_lsp.nvim',
    event = 'BufRead',
    config = function()
      require('py_lsp').setup()
    end
},

which also did not work for me! I usually setup my plugins outside of the packer startup callback function. So try calling require('py_lsp').setup() outside of it. This works for me.

[jonesmartins]

So using virtualenvs.in-project will not make a difference regarding dependency resolution.

You're totally right. It's just easier for me to know where things are, at the end of the day, and also kind of like what PyCharm did.

which also did not work for me!

Calling require('py_lsp').setup() near the end of my config file doesn't work for me, and my config is:

use { 
   'HallerPatrick/py_lsp.nvim',
    config = function()
      require('py_lsp').setup()
    end
},

Calling :PackerCompile to turn Pyright on still works, though.

[HallerPatrick]

Yeah, I find :PackerCompile confusing sometimes, as it auto executes code that is compiled into a Lua file.

BTW, how did you install pyright the lsp-installer sometimes does not work with py_lsp?

[jonesmartins]

I installed pyright through Mason.nvim. Pyright works with global Python by default. Trying to run it with local venvs didn't work (neither did pylsp), so I looked for discussions about it on GitHub and found issue #500 at the nvim-lspconfig repo. Having tried all solutions there, including hard-coding a .venv path in config.settings.python.pythonPath and config.settings.python.venv_Path—and failing, —I found your plugin, and it worked! So thanks. :-)