Multi-root workspace: "Python: Run Selection/Line in Python Terminal" sends selection to wrong workspace Python Terminal

[munro]

Issue Type: Bug

Behaviour

Expected vs. Actual

Expected

1. Send a selection to workspace A's Python Terminal
2. Switch to a file in workspace B.
3. Sending a selection from workspace B's file should send to workspace B's Python Terminal (and launch it if necessary).

Actual

1. ✅ Send a selection to workspace A's Python Terminal
2. ✅ Switch to a file in workspace B.
3. ❌ Sending a selection from workspace B's file get sent to workspace A's Python Terminal.
4. ❌ And if I close workspace A's Python Terminal, sending a selection from workspace B will recreate workspace A's Python Terminal.

Steps to reproduce:

1. Setup a multi-root workspace with 2 projects.
   1. Setup a Poetry environment for each project.
   2. Install different packages into sub-workspace, and also different Python versions.
      This is demonstrate the issue with sending the selection to the wrong workspace Python Terminal.
   3. Create a new workspace and each sub-workspace to it using {"folders": [...]} .
   4. ✅ Make sure Python: Start REPL works for both workspace, so that you have a different cwd & different Python packages and/or Python versions.
2. Reproducing the bug
   1. Switch to a file in workspace Foo.
      1. Make a selection in workspace Foo.
      2. Execute Python: Run Selection/Line in Python Terminal
      3. ✅ Verify that it launched workspace Foo's Python Terminal, and sent the selection there.
   2. Switch to a file in workspace B
   3. Make a selection in workspace B, try doing an import ... for a package that was install in workspace B but not A.
   4. Execute Python: Run Selection/Line in Python Terminal
   5. ❌ Bug should have occured, the selection will be sent to workspace A, and not worskpace B. And if you sent code that only works workspace B, you will see a Python exception.
   6. Now, close workspace A's Python Terminal, and hope 🙏 that when you run the selection in workspace B, it will relaunch the Python Terminal for workspace B. 🥺
   7. Execute Python: Run Selection/Line in Python Terminal
   8. ❌ 😢 Bug should have occured, workspace A's terminal will relaunch, and workspace B's selection will be sent there.

Diagnostic data

• Python version (& distribution if applicable, e.g. Anaconda): 3.10.2
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Poetry
• Value of the python.languageServer setting: Pylance

User Settings

defaultLS: {"defaultLSType":"Pylance"}

downloadLanguageServer: true

envFile: "<placeholder>"

venvPath: "<placeholder>"

venvFolders: "<placeholder>"

condaPath: "<placeholder>"

pipenvPath: "<placeholder>"

poetryPath: "<placeholder>"

languageServer: "Pylance"

linting
• enabled: true
• cwd: "<placeholder>"
• Flake8Args: "<placeholder>"
• flake8Enabled: false
• flake8Path: "<placeholder>"
• lintOnSave: true
• banditArgs: "<placeholder>"
• banditEnabled: false
• banditPath: "<placeholder>"
• mypyArgs: "<placeholder>"
• mypyEnabled: false
• mypyPath: "<placeholder>"
• pycodestyleArgs: "<placeholder>"
• pycodestyleEnabled: false
• pycodestylePath: "<placeholder>"
• prospectorArgs: "<placeholder>"
• prospectorEnabled: false
• prospectorPath: "<placeholder>"
• pydocstyleArgs: "<placeholder>"
• pydocstyleEnabled: false
• pydocstylePath: "<placeholder>"
• pylamaArgs: "<placeholder>"
• pylamaEnabled: false
• pylamaPath: "<placeholder>"
• pylintArgs: "<placeholder>"
• pylintPath: "<placeholder>"

sortImports
• args: "<placeholder>"
• path: "<placeholder>"

formatting
• autopep8Args: "<placeholder>"
• autopep8Path: "<placeholder>"
• provider: "black"
• blackArgs: "<placeholder>"
• blackPath: "<placeholder>"
• yapfArgs: "<placeholder>"
• yapfPath: "<placeholder>"

testing
• cwd: "<placeholder>"
• debugPort: 3000
• nosetestArgs: "<placeholder>"
• nosetestsEnabled: undefined
• nosetestPath: "<placeholder>"
• promptToConfigure: true
• pytestArgs: "<placeholder>"
• pytestEnabled: false
• pytestPath: "<placeholder>"
• unittestArgs: "<placeholder>"
• unittestEnabled: false
• autoTestDiscoverOnSaveEnabled: true

terminal
• activateEnvironment: false
• executeInFileDir: "<placeholder>"
• launchArgs: "<placeholder>"

experiments
• enabled: true
• optInto: []
• optOutFrom: []

insidersChannel: "off"

tensorBoard
• logDirectory: "<placeholder>"

Extension version: 2022.2.1924087327
VS Code version: Code 1.65.1 (8908a9ca0f221f36507231afb39d2d8d1e182702, 2022-03-08T02:20:04.372Z)
OS version: Darwin arm64 21.2.0
Restricted Mode: No

System Info

Item	Value
CPUs	Apple M1 Max (10 x 24)
GPU Status	2d_canvas: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	6, 9, 11
Memory (System)	64.00GB (0.16GB free)
Process Argv	--crash-reporter-id REMOVED
Screen Reader	no
VM	0%

[karthiknadig]

Turning this into a feature request, since we don't support this for now. We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

[Samuel-Therrien-Beslogic]

Overlap with #18650 (comment) , I'll copy my comment from there:

One of the projects I work with is a microservices monorepo
Each service (as well as the common/shared code library/module) have their own .venv
As a workaround I've created a virtual environment at the root of the project and pointed defaultInterpreterPath to it "python.defaultInterpreterPath": ".venv/bin/python", so everything is installed there.
And changed all my debug tasks commands to use the ${workspaceFolder} ("command": "cd backend/services/collect-service; poetry run ${workspaceFolder}/.venv/bin/python run.py",).

But this really isn't the best and is bound to have issues as soon as there's version conflicts between services. It would be nice if VSCode devs didn't have to do that extra setup and could have scoped virtualenvs (which those using PyCharm don't have an issue with)

[brettcannon]

Thank you for submitting your feature request and everyone who considered it! Unfortunately this issue did not receive enough votes over the allotted time, and so we are closing the issue.