I have a project that includes multiple, unconnected git repos, which I check out next to each other in my ~/dev folder.
One repo, ~/dev/multitenant, is the "main" project, and there are several libraries that Multitenant imports, including ~/dev/airspace. Both of these folders are in the VS Code Workspace I built for Multitenant.
A copy of Airspace is installed via uv and Multitenant's pyproject.toml in ~/dev/multitenant/.venv, which is the Python environment that's activated in my Workspace.
One of the files in Multitenant does this:
from airspace.utils import get_block_tuple
When I perform 'Go to Definition' on get_block_tuple from that file, I want the the file ~/dev/airsapce/airspace/utils.py to open. Instead, the file ~/dev/multitenant/.venv/lib/python3.11/site-packages/airspace/utils.py is opened.
How do I make VS Code open the checked out file in my Airspace repo, instead of the installed file in my virtualenv? That's important because the primary reason I use Go to Definition is to make edits to Airspace, and editing the copy installed in the venv is useless.
I just switched from PyCharm, which would do this because I had associated Airspace's PyCharm project as a child of Multitenant's PyCharm project. Does VS Code have any sort of equivalent functionality? I have both folders in my VS Code Workspace, so I figured this would just work.
I've done some previous googling on this, and learned about the VS Code setting python.analysis.extraPaths, but that doesn't seem to help. I also tried doing uv pip install -e ../airspace, which successfully installed my local Airspace repo into my venv, but VS Code just stops being able to recognize imports from Airspace after that, giving me the dreaded yellow squiggle.
Oh shoot, I figured it out! I was using python.analysis.extraPaths wrong.
I'm used to specifying library overrides in docker-compose.yml volume mounts, where you have to include the path all the way up to the package folder in order to override the library folder in site-packages. But what I actually had to do was include the path only up to the repo folder!
What I did that worked was to add this to my multitenant.code-workspace file (or VS Code's settings.json):
"python.analysis.extraPaths": [
"${workspaceFolder:airspace}",
],
That adds ~/dev/airspace to the PYTHONPATH, which then allows the ~/dev/airspace/airspace folder, where the actual code is, to be importable. It even overrides the still-installed copy of Airspace in ~/dev/multitenant/.venv, which is perfect!