"Rename symbol" and "Go to references" are incomplete in multiroot workspace

[ErwanDL]

Environment data

• Language Server version: v2020.7.2
• OS and version: macOS 10.14.6
• Python version (& distribution if applicable, e.g. Anaconda): 3.7

Expected behaviour

In a multiroot workspace where different workspaces use each other as packages, when using the actions "Rename symbol" (resp. "Go to references") on a symbol, it should rename (resp. find references of) the symbol across all workspaces, and not just the current one.

Actual behaviour

"Rename symbol" only renames occurrences of the symbol in the current workspace. Similarly, "Go to references" only shows references of the symbol in the current workspace.

Steps to reproduce

Here is a sample project that illustrates this bug : https://github.com/ErwanDL/pylance-multiroot-example

• Clone the project.
• Open the multiroot workspace (you should have two sub-workspaces workspace1 and workspace2).
• Create a venv in each workspace.
• Install workspace1 as a package for workspace2 by cd-ing to workspace2 and running $ pip install -e /path/to/workspace1.
• Find the class Foo in workspace1/pkg1/foo.py. Use "Go to references" on this class : notice that it does not reveal that the class is used in workspace2/pk2/baz.py. Similarly, rename the class using "Rename symbol" : the class will be renamed where it is used in workspace1, but not in workspace2.

In this GIF I try to rename the class Foo, you can see it is properly renamed in all files of workspace1, but not in workspace2.

[jakebailey]

Just to update this, this is due to the internal way we handle multiple workspaces. Each workspace is its own "program" (basically "the analysis"), but aren't aware of each other. This can lead to states where one workspace may refer to a file in the other but not vice versa, and therefore when you search for things only one of them actually knows the other exists. This is a known limitation at the moment.

(But, I think our current state is still an improvement over the old language server whose multiroot support was iffy at best.)

[ErwanDL]

I see, indeed this does not seem to be an obvious change, but it would be very appreciated if it was handled 🙂 Refactoring is one of the rare areas where PyCharm still has an edge, but I'm loving all the work you put in to bridge the gap ❤️

[fkromer]

Refactoring is one of the rare areas where PyCharm still has an edge, but I'm loving all the work you put in to bridge the gap heart

The refactoring features in combination with good overview over changes (GitLens) after refactorings are one of the advantages in comparison to command line based editors like vim, spacemancs, etc. Features like that are what makes VSCode stand out actually. If they work. BTW there is still the Jedi language server as fallback :)

[JosXa]

rare areas where PyCharm still has an edge

+1 on this. The old language server was a nightmare, but with Pylance things are really changing to the point where I'm now almost ready to make the switch. JetBrains are either incapable of or indifferent about adding proper typing and giving PyCharm the love it deserves, so I'm really looking forward to Pylance catching up in those other last remaining areas and unifying my IDE experiences.

[judej]

Moving this issue to discussion as an enhancement request for comments and upvotes.

[dgcnz]

Is there any update on this issue?

[erictraut]

Relative to other enhancement requests, this one hasn't received many upvotes.

[parched]

Each workspace is its own "program" (basically "the analysis"),

Instead of being per workspace, could it be per venv/interpreter instead? That would suit my team's use case.

[geesecross]

+1 for this feature in 2025.