Activate selected directory's environment within a multi-root workspace with different environments

[cnpryer]

Looked around for open issues related to my problem; I could only find #690 -- which has been closed.

To summarize, I have several different projects mapped using [workspace name].code-workspace and in each there is a .vscode/ containing settings.json with:

{
    "python.pythonPath": "venv\\Scripts\\python.exe"
}

Environment data

• VS Code version: 1.49.3
• Extension version (available under the Extensions sidebar): N/A
• OS and version: Windows 10.0.18362 Build 18362
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.8.5 64bit
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
• Relevant/affected Python packages and their versions: N/A
• Relevant/affected Python-related VS Code extensions and their versions: N/A
• Value of the python.languageServer setting: N/A

Expected behaviour

On integrated prompt launch activate project's venv using its ./.vscode/settings.json.

Actual behaviour

Uses the first project's venv.

Steps to reproduce:

See this comment for a really good example.

Reproducing my specific example:

1. Set up multi-root workspace.
2. Add venv to each folder in workspace using python -m venv venv from within the folder or pointing it to the root of the directory.
3. Close all files but leave workspace open.
4. ctrl+shift+" ` " to launch new terminal.
5. Select a directory other than the first one (gif).

NOTE: as an update (I've been playing around). The expected behavior occurs by doing the following:

1. Create the multiple-root workspace in vscode (1 & 2 from my specific example above).
2. Open a file within the directory you intend to activate your environment automatically by launching the terminal.
3. f1-> Terminal: Create New Terminal (In Active Workspace).

Logs

NOTE: could not figure out how to get the logs for the integrated terminal/workspace automation.

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS D:\github\ortools-pyinteractive> & d:/github/solverstack/solverstack-crud/venv/Scripts/Activate.ps1
(venv) PS D:\github\ortools-pyinteractive> 

[brettcannon]

We have marked this issue as "needs decision" to make sure we have a conversation about your idea as we don't view this as a bug (it's really hard to infer what the user wants in a multi-root workspace with differing interpreters, e.g. did you mean to have that file open when you launched the extension or did it just happen to be open from when you last quit VS Code?). We plan to leave this feature request open for at least a month to see how many 👍 votes the opening comment gets to help us make our decision.

If the automatic activation is not working for you it is possible to disable it so you can manually activate whichever environment you prefer.

[cnpryer]

Thanks for the response. My specific setup might be a bit different than the comment I linked, but it's relatively similar with the main difference being that my virtual environment is python venv located within the individual roots (each folder). I guess maybe I should have been more descriptive of what I was expecting given my specific setup.

On launching New Terminal (crtl+shift+ " ` ") I am prompted with "select a current working directory for the new terminal". If configured via ./.vscode/settings.json, at that specific directory I selected, it would activate an environment using that python.pythonPath setup. I believe this is how it works if it is in its own workspace (using ${workspaceFolder}/path/to/python.exe).

Maybe this is just a user error and there is a way to do this. I'll play around.

it's really hard to infer what the user wants in a multi-root workspace with differing interpreters

This definitely sounds fair, maybe there is a way to not infer anything if it is not setup within a root-specific .vscode/settings.json, i.e. launch a regular prompt with default integrations. I'm not familiar with how some users may use this feature outside of the python venv world, so I totally understand if there's tons more complexity behind this than I realize.

did you mean to have that file open when you launched the extension or did it just happen to be open from when you last quit VS Code

What extension are you referring to?

If the automatic activation is not working for you it is possible to disable it so you can manually activate whichever environment you prefer.

This could be ideal for now. Thanks!

I also would like to rename the title of this issue to something other than "Activate the environment for the open file in a multi-root workspace with differing environments" since that's not specifically my issue. A better title might be "Activate selected directory's environment within a multi-root workspace with different environments".

[cnpryer]

Here is a gif of the use-case. d:/github/solverstack/solverstack-crud/venv/Scripts/Activate.ps1 is the incorrect environment and I do not have any file open.

[cnpryer]

Updated the original post.

[brettcannon]

What extension are you referring to?

Our extension: the Python extension for VS Code.

[nikogeg]

Any updates on this?

[brettcannon]

@nikogeg nope; we would post if we had anything to share.

If someone wants to propose a solution, discuss it with us, and the submit a PR we would be happy to have such a discussion.

[ccrvlh]

I have a similar use case. We have a workspace with 5 different projects, each with it's own venv. Everytime we open a new terminal window (without explicitly selecting which working directory), it opens up the terminal for the first directory on the workspace, even though the terminal itself is on the current working directory, which makes things inconsistent: the current working directory terminal with the first workspace directory venv.

[j-m]

Slight variation but didn't seem worth making a new issue:

We use .vscode/settings.json for personal settings and .code-workspace's settings for anything that should be shared, so { "python.pythonPath": "venv\\Scripts\\python.exe"} isn't in settings.json.
Which means we run into the same problem, there's no way to define pythonPath per workspace folder in .code-workspace.

So, is it possible to add the ability to map python path per-workspace-folder? e.g.

    "python.pythonPath": {
      "${workspaceFolder:project1}": "${workspaceFolder:project1}/venv/Scripts/python.exe",
      "${workspaceFolder:project2}": "${workspaceFolder:project2}/venv/Scripts/python.exe",
      "${workspaceFolder:project3}": "${workspaceFolder:project3}/venv/Scripts/python.exe",
    },

Does pythonPath even exist any more?

[karrtikr]

Does pythonPath even exist any more?

@j-m Nope, python.defaultInterpreterPath now replaces it, although its behavior varies a bit, see https://github.com/microsoft/vscode-python/wiki/AB-Experiments#tldr

We use .vscode/settings.json for personal settings and .code-workspace's settings for anything that should be shared

Regarding the other ask, .vscode/settings.json is considered sharable as well, so you should ideally add the setting to each workspace folder settings.json file instead.

#18650 could also potentially help handle this scenario.

[cnpryer]

To be honest I've moved away from doing this since this issue.

[j-m]

considered sharable

We've gitignored the whole .vscode folder; it's user settings on a per-project basis. If you share settings you'll end up fighting other dev's preferences, variations in local environments, and slowly build up deprecated/unused/incompatible configs. Looking through the issues, this even looks to be one of the main reasons pythonPath was deprecated

---

#18650 looks pretty good, but I'm not sure I've correctly understood what's actually changed. Could you elaborate, please? I think that feature lets you share an interpreter for all workspace folders, while this ticket is asking for a different interpreter for each workspace folder.

I couldn't get the Python: Select interpreter command to work. It lets you specify the interpreter for each folder, but activates the wrong one (looks like it uses the one you most recently set - which is what I would've expected the "Select at workspace level" option to do).

[ReveStobinson]

Reading through this thread after experiencing this issue and I have what I hope is a potential solution @brettcannon, but likely not enough knowledge of TypeScript to implement it myself.

It seems like the big disconnect here boils down to the extension's behavior when receiving the Terminal: Create New Terminal command, vs the Terminal: Create New Terminal (In Active Workspace) command. If no active terminals exist, the latter command is what is called by e.g. the Ctrl + ` shortcut.

Terminal: Create New Terminal activates the environment associated with that directory's selected interpreter. If it has none, it will activate the workspace interpreter's env. If the workspace also has none, it will not activate any environment at all.

Terminal: Create New Terminal (In Active Workspace) activates the environment associated with the first folder in the workspace (even if the working directory doesn't have an interpreter selected and the workspace itself does!)

Especially given that last point, I really think the current (In Active Workspace) behavior is undesirable and not what one might expect. At the very least, I think that this should be user-configurable to one of two behaviors when opening a terminal in a multi-root workspace (perhaps adding a true/false option called python.terminal.activateInWorkspace or something):

1. true: All new terminals created will use the working directory to select an interpreter (i.e. behavior of Terminal: Create New Terminal (In Active Workspace) will mirror the current Terminal: Create New Terminal -> <selected directory> behavior.
2. false: Current behavior, the environment activated by the python extension will always default to activating the environment of the interpreter associated with the first folder in the workspace, regardless of the working directory or the workspace interpreter settings.

[brettcannon]

It's on our iteration plan to take a fresh look at our terminal story and the multi-root part will play into it. But beyond that there are no updates.

[eavonius]

Awesome, definitely looking forward to this as well!

[karrtikr]

Closing as dup of #15522 which fixes the issue. Feel free to let us know if you still face the issue and we'll be happy to have another look.