definition not found when opening from file manager

[Gennaro Tedesco]

I am using coc-jedi via :CocInstall coc-jedi and I have noticed the following behaviour: when opening a file in a python project

• via a file manager (any of the vifm, ranger and similar)
• via vim-startify

the gd <Plug>(coc-definition) returns [coc.nvim] Definition not found; a similar case is described here. The behaviour is instead fine if opening files via command line nvim/vim /path/to/file.py. The above scenarios work (and do not work, respectively) both in virtual environments and in global ones (therefore I would exclude that it is due to some mysterious virtual environment configuration settings lost somewhere).

What mechanism can this be traced back to?

[Samuel Roeca]

Hmm, I'm not entirely sure! Have you found any clues in the past 16 days?

[Gennaro Tedesco]

I suspect it may be due to the fact that when opening a file via the command line full path (say vim /path/to/file) the entire path is passed/appended, therefore jedi discovers the location of the project dependencies (in this case /path/), which may not be the case when using Startify or a file manager (I do not know how they pass the file locations to the editors).

This is however only an (un)-educated guess since I do not really know how jedi manages dependencies internally, so I was hoping you could shed some light on how this happens so that we can narrow down what to look into.

[Samuel Roeca]

Revisiting this, it's possible that when you open a file with the file explorer, your workspace path is higher up your file system than the module that you've opened. This, in turn, might make it hard for Jedi to figure out where to look for files.

Would you be able to provide a minimal example so I can reproduce on my end? I suspect this has to do with your working directory, but as you alluded to above, that's just one possibility.

[Gennaro Tedesco]

Take the following example:

mkdir src
cd src
touch utils.py 
touch main.py

src
   ├── main.py
   └── utils.py

## utils.py

def test():
    return True

## main.py

from utils import test
test()

If you open those files via, say vim src/main.py then go-to-definition does work, namely gd on test does bring you to utils.py. However, if instead one opens those files via a file manager from any location (both from the location of the files themselves and their parent folders) the error occurs.

I tried to even explicitly export PYTHONPATH=. to no avail.

[Samuel Roeca]

Thanks for providing the example! I've never played with ranger before, it's a really nice tool.

Strangely, in my setup, everything works perfectly out of the box. I made sure to keep my example as close to yours as possible.

• OS: Linux Mint 20.1
• Terminal: zsh running in tmux within Alacritty
• Editor: nvim v0.5.0-dev+1182-gb79596eb5
• coc-jedi version: 0.25.1
• jedi-language-server version: 0.30.1

Since things appear to work correctly on my machine, would you be able to provide more information about your environment?

[Gennaro Tedesco]

I have narrowed down the problem, seemingly, to the case where imports are obtained by pre-fixing folder paths: for instance whenever the import is of the form

from pkg.module import function

rather than simply

from module import function

which is often the case for package projects. If, in your example, you pre-pend from src.utils import test you will see the error appearing. If, however, you do have relative imports still but open the files as vim src/main.py then all works fine.

The example above makes use of vifm rather than ranger (but it does happen on the latter as well).

[Samuel Roeca]

I believe this is a behavior rooted in coc.nvim and has to do with your root path. When you use a file explorer like ranger, your root path will be the same directory as the file you're opening. When you open a file directly with Vim, your root path is your current working directory. See this GIF:

When Vim's current working directory is deep within a project's tree, things like relative imports won't work correctly. They ONLY work when Vim's current working directory (and, therefore, your LSP workspace) can be outside of the package where relative imports take place.

In short: if you want relative imports to work correctly, you should generally open Vim in the root of your project. Some file explorers seem to prevent this from happening.

[Samuel Roeca]

Try cding into src, opening main.py directly with vim, and then going to definition. You'll notice the exact same behavior you get with the file explorer.

[Gennaro Tedesco]

Yes, what you are saying is correct. However, this does seem to be python related only, because for some other languages coc.nvim references work fine even via file manager (for example I checked in lua and go).

This said, not that this is a big problem, thank you for looking into it anyway!