Local developping modules ill referenced by VSCode's "go to definition"

[francoisWeber]

Context

Environment from poetry debug info :

Poetry
Version: 1.5.1
Python:  3.11.5

Virtualenv
Python:         3.11.5
Implementation: CPython
Path:           /Users/f.weber/Library/Caches/pypoetry/virtualenvs/query-index-attribution-bB1GeDKq-py3.11
Executable:     /Users/f.weber/Library/Caches/pypoetry/virtualenvs/query-index-attribution-bB1GeDKq-py3.11/bin/python
Valid:          True

System
Platform:   darwin
OS:         posix
Python:     3.11.5
Path:       /opt/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.11
Executable: /opt/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.11/bin/python3.11

OS is Mac Ventura 13.3.1

I consider a mono-repo holding a main pyproject.toml (see sanitized version here) that mainly references a few sub-libraries of my own ; among them a certain some_local_lib. Each sub-lib has a dedicated pyproject.toml holding its own requirements. See a gist for the pyproject.toml of some_local_lib here.

As shown on the gist, the main pyproject.toml requires some_local_lib with a relative path and a develop = true tag:

some_local_lib = { path = "./lib/some_local_lib/", develop = true }

Finally, I have a few scripts in the project's directory that use from some_local_lib import stuff to work.

When I want to init or reset my project, I just type poetry install in order to get every reqs in the virtualenv + making venv's Python aware of my local some_local_lib. Everything works fine so far and I can launch my scripts without trouble.

Description of the problem

My problem occurs on VSCode (I don't know if this could happen elsewhere) when I use the "go to definition" (keyboard F12) feature of some symbol some_symbol imported from some_local_lib through from some_local_lib.stuff import symbol. I expected this to open the symbol's definition from the path root_dir_of_project/lib/some_local_lib/stuff.py. What actually happens is that it opens /Users/me/Library/Caches/pypoetry/virtualenvs/my_project_someHash-py3.11/lib/python3.11/site-packages/some_local_lib/stuff.py.
This is very annoying since I actively work on these sources and I would like Poetry/VSCode to open the working version of stuff.py, not the packaged and frozen version of it.

Is it a bug or rather a misuse of the Poetry configuration ?

Thank you :)

[dimbleby]

please figure out whether this is a poetry question or a vscode question

I expect that poetry is correctly installing the path dependency in the virtual environment that it manages, and you have vscode picking up some other virtual environment.

If so, there is nothing that poetry can do about that

[lyogev]

I think it may be related to this issue
microsoft/pylance-release#3473
I wonder how poetry can help support compat/strict editable mode

[dimbleby]

ah yes, that sounds right. Not a poetry bug then.

[francoisWeber]

Ok my bad, guys :) Thanks for highlighting the related PyLance issue :) I'll close the issue.

[manulera]

@francoisWeber Did you figure out a workaround?

[francoisWeber]

Not yet but I had no time to dig into this problem for the moment.

[francoisWeber]

Hi Guys,
I found no solution for this issue but I figured out something new, so I reopen it.
I refer to my first message when I show the Description of the problem. I recall the problem occurs when I refer to the library some_local_lib which has option develop = true and is at root_dir_of_project/lib/some_local_lib in another script belonging to the same project. VSCode does not reference it through its local path root_dir_of_project/lib/some_local_lib but through an poetry-installed version located in the site-packages of Poetry's virtualenv.

So I have the following question to reopen this issue : why would Poetry install a library with option develop = true (in my example some_local_lib) inside its site-packages rather than just using the local version ? Maybe VSCode confusion comes from this first problem ? What do you think ?

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.