Currently we aren't passing the resource: Uri value into most methods.
This would result in various parts of the extension not working correctly in a multi-root environment (current code will pick settings from first available workspace folder).
Examples:
This only applies to multi-root environments.
The problem is what would we pass for the resource? The iPython kernel applies to all open python files. Otherwise we'd have to have multiple kernels running? I guess that's an option too.
The problem is what would we pass for the resource?
The uri of the open python file.
The iPython kernel applies to all open python files. Otherwise we'd have to have multiple kernels running? I guess that's an option too.
Yes, else here's the bug:
I think we'll have to do something like look at all of the active python files and find the one with jupyter installed in it.
That's wrong. The user should be making the decision, not us.
The whole point of integrating with the extension is lost, the user decides what python version is to be used in the current workspace, we should maintain that, we could display a prompt asking them if they would like to change it.
Else we have some major inconsistencies with the, python extension.
We might also need to allow the user to pick if say they start without opening a file first or even if there are multiple.
Is this in the pipeline for some future release? :slightly_smiling_face:
Not at the moment, no. Our 'backlog' or 'inprogress' pipelines are what we're currently working on.
It does have a lot of votes though.
I'm moving it to New Issues so we triage it again.
are these pipelines public? not sure where I can find them
To start, let's just make sure we're honoring the active python version on first start of the interactive window.
@ollema I think you have to install zenhub to see the issues? Not sure.
Here's what it adds for me:

This is the branch where I started this work:
https://github.com/microsoft/vscode-python/tree/rchiodo/multiple_workspace_kernel
The resolution of this should let the user
I just ran into this.
I am working with a workspace that includes multiple folders.
Each of those folders has its own venv (via pipenv), that gets correctly detected by vscode. Normal .py files execute as expected with the selected interpreter. Also bottom-left displays the correct interpreter.
Now in a file that contains cells (imported from a .ipynb file), running a cell is supposed to start up the jupyter server. Now I do expect it to look for the jupyther installation in the currently selected interpreter (venv), but instead it tries to find it in the interpreter version assosiated with the topmost folder. If this folders interpreter does not have jupyter installed, it will issue a warning and (interestingly) uses the closest match, which is a interpreter in some of the other subfolders.
I saw other issues with conda environments, but I do use a plain python install.
I am on windows 10, running vscode inside the WSL.
I could test any fixes, if needed.
The fix isn't that hard, just haven't had the time to finish it yet. I'm going to move this bug back to triage to see if we can bump up the priority.
Work is started here: https://github.com/microsoft/vscode-python/tree/rchiodo/multiple_workspace_kernel
I believe this is the same issue I'm having. I have two environments through anaconda, Both have jupyter. Script will run through the terminal in vscode, but not through Python interactive. Using sys.version shows python interactive is using a different interpreter than VSCode overall.
Is anyone aware of a fix for this?
While a proper fix is in progress, a work around is to create a new workspace with a single root, with the root being the project you want to run jupyter interactively. It works in this reduced use case
@TeraInferno can you expand on the below.
While a proper fix is in progress, a work around is to create a new workspace with a single root, with the root being the project you want to run jupyter interactively. It works in this reduced use case
I have some environments that run a Python Interactive shell and some that do not. I cannot pin down the difference between them What is the best current way to start a new project with a virtual environment in vs code that can use Python Interactive?
The spec part of this issue is based on how to pick a kernel. We're going to solve both allowing per file python selection and kernel selection at the same time.
This is being addressed through microsoft/vscode-jupyter#1379
Actually this wasn't entirely addressed through microsoft/vscode-jupyter#1379. We still don't use the file to pick the environment.
This doesn't look resolved to me.
What I did
Folder A
Folder B
Create envA in A and envB in B
Opened up a workspace with both folders added to it. Selected envA for a file test.py in A and envB for a file test.py in B. When I did "run selection / line" in test.py in file B instead of using envB it tried to install ipykernel in envA.
Did you verify that the file in B that the environment actually stuck? Seems there's a bug in the base extension where you have to switch back and forth between the files.
For example, what does 'Python: Run in terminal' do?
Sorry will report back in just a bit. Having funny issue with my python virtual envs.
@rchiodo . Good call. I'm pretty darn sure that I had the scenario right, so it was probably that core bug. This time I swapped back and forth a few times and ran both of them in the terminal and it did launch with the correct env this time. Validated.