Discovery of stubs in a different folder

[Jasha10]

I'm having trouble with discovery of .pyi stub files that live in a different folder from the .py source file.

Here is an example that works as expected:

.
├── code
│   ├── foo.py
│   └── foo.pyi
└── main.py

If I set the environment variable PYTHONPATH=code and if main.py contains the line from foo import bar, then jedi#goto_stubs() works as expected (it finds the definition of bar in code/foo.pyi).

Here is an example that is not working:

I am having problems when the file layout looks like this:

.
├── code
│   └── foo.py
├── stubs
│   └── foo.pyi
└── main.py

In this situation, jedi#goto_stubs() does not work.
I have tried the following environment variable settings:

• PYTHONPATH=code:stubs
• PYTHONPATH=code MYPYPATH=stubs

I would expect that the .pyi file can be discovered as long as it is discoverable on PYTHONPATH or MYPYPATH, but this seems not to be the case.

[davidhalter]

Jedi does not respect MYPYPATH, because it's fundamentally not mypy ;-)

Jedi follows this: https://peps.python.org/pep-0561/#type-checker-module-resolution-order

I guess just put stubs in front of code in the PYTHONPATH.

[Jasha10]

Jedi does not respect MYPYPATH, because it's fundamentally not mypy ;-)

Makes sense!

Jedi follows this: https://peps.python.org/pep-0561/#type-checker-module-resolution-order

I guess just put stubs in front of code in the PYTHONPATH.

Using PYTHONPATH=stubs:code I am still getting jedi-vim: Couldn't find any definitions for this when I call jedi#goto_stubs().

[davidhalter]

I'm keeping this open for now, but I feel like this might not be fixed, since currently nobody is actively working on Jedi.

I'm currently working on a Rust replacement for Jedi, but it will still take time (and it will probably support MYPYPATH).

[Jasha10]

Cool! I can't wait to see the new rust program.