When VS Code is launched from a terminal with an activated environment, select it

[brettcannon]

For both virtual and conda environments, if you launch VS Code from an activated environment, we should pick that up and automatically select that environment for the user if no environment had been previously selected.

One open question, though, is what to do if you had an environment previously selected? Do we:

1. Ignore the one you launched VS Code under?
2. Automatically select the activated one?
3. Prompt to see whether you want to keep your previously selected environment or switch to the activated one?

[paulacamargo25]

The team discuss this and we decided that we will select the activated environment if there is no environment explicitly selected by User.

[greazer]

I had a pretty long conversation with Kartik about this as I reached out to him with the same suggestion to which he then pointed me here. :)

Not only do I think that we should do this (select the activated environment), I'd like you to consider a couple more options...

1. Ensure that the activated environment overrides any selected environment the user has set in settings.
2. Ensure that the activated environment is only applicable during the lifetime of that VS Code session (across reloads of cours)
3. This is the kicker... Don't allow the user to change the active environment at all in this mode.

IMHO I think this mode of operation is special. If a user wants to have total control of what environments are actively being used, then don't start it from within an environment. It's the old model we have.

This is the way tools like Jupyter operate after all. When a user starts Jupyter from an activated environment (most do), then they cannot change it to anything else unless they restart Jupyter under a new environment (this isn't totally true, as kernels can be registered to be choosable. Most of the time this isn't done though).

Doing this can help simplify the notebook story for many of our users. I also think that it can simplify the kernel selection model for Python-only users. I.e. don't want to be bothered learning how to select different interpreters in VS Code? Just launch a new environment and start vscode from there. Done.

[rchiodo]

How do you detect this condition? I launch VS code from a command line all the time. The environment in this situation is my global python. Do you skip this logic for a global python?

I think your number 3 is a big no-no. You're assuming way too much. Sure it can pick the default, but I should be able to change it.

[greazer]

I don't know how we detect whether the user is in an environment or not. With conda I'm sure we can based on environment variables or just looking at the available interpreter path. I'm guessing we can with other environment managers too.

For no. 3, this is the key point, and I'm going to stand by it. If you want to be able to change the Python interpreter, then don't start vscode from within an activated environment. I'm guessing most vscode Python users do this today anyway, so it'll be a no-op for the vast majority of those users. In the Jupyter world, my proposed model is the norm.

BTW, we could notify the user somehow that they are in this mode, or the commands that support changing the active Python environment could still exist, and if invoked, could tell them that they're in this mode with a "Learn more".

[kieferrm]

The general idea makes sense. I agree with @rchiodo on number 3. Depending on your OS, if you have installed conda you might always have a base environment activated. So, at this moment all CLI launches of vscode happen inside an activated environment.

Number 1 has a lot of corner cases such as

• code . launches vscode. At this moment historic windows are restored. For those windows, their previously selected environments should be respected
• code . gives focus to an already open window in a running vscode instance. No environment change should happen at this moment.

[karrtikr]

if you have installed conda you might always have a base environment activated

Another situation: A common workaround for conda issues today is to use the Anaconda prompt to launch VSCode which already has base activated. In this case they would still expect to change their conda env to any new ones they create.

[greazer]

For sure the code . scenarios need to be addressed, though I think they can be handled in a reasonable way (notifications, errors, if necessary) if we went this direction. Example. Let's say that the user had FolderA opened with the A environment active. If the user launches code from the B environment, then a few things could happen.

• Tell the user that FolderA was already opened with a different active environment and abort.
• Tell the user and offer to reload FolderA with the B environment.
• Support having separate instances of FolderA being using the environment as a differentiator.

For no. 3, yes, users could have a base environment activated and so they would be limited to just that base environment. That's exactly what I'm implying. This doesn't seem to be a big problem as they may want to work in the base environment OR if not they'd just activate the environment they want before launching. Alternatively, this could be considered a special case for anaconda provided we can detect that they are in the base environment. As long as the user stays within the anaconda environment list, allow them to choose any of them. I would guess that for users who use an anaconda base environment, it's unlikely they'd wander outside of anaconda.

Another idea would be to provide a flag allowing the user to enforce ignoring the activated environment (and operate like we do today). Though I think the fact that a user has started code from within an activated environment at all, especially an anaconda environment, it may not be possible to completely ignore it and has been the source of problems in the past.

[brettcannon]

Not only do I think that we should do this (select the activated environment), I'd like you to consider a couple more options...

1. Ensure that the activated environment overrides any selected environment the user has set in settings.

I plan to test this out in WWBD.

2. Ensure that the activated environment is only applicable during the lifetime of that VS Code session (across reloads of course)

I don't quite follow here. You say the chosen environment "is only applicable during the lifetime of that ... session", but you always say that it should persist "across reloads of course". To me that seems contradictory. Are you suggesting that the selection of the activated environment is ephemeral and forgotten once VS Code is quit?

3. This is the kicker... Don't allow the user to change the active environment at all in this mode.

I don't think this can be a mode; it's all or nothing. So either we say you must launch VS Code from a shell with an activated environment (which isn't possible for those that launch from a shortcut on their desktop), or you have the option to potentially undue your mistake of using the wrong environment in your shell for your workspace. It also isn't applicable across workloads to lock you into what you launched with: if I have multiple environments set up for different Python versions I shouldn't have to quit VS Code just to change my environment.

How do you detect this condition? I launch VS code from a command line all the time. The environment in this situation is my global python. Do you skip this logic for a global python?

Both venv and conda set environment variables when an environment is activated. I personally plan to check for those environment variables during activation, and if they are set then forcibly set the environment via WWBD.

[DonJayamanne]

Both venv and conda set environment variables when an environment is activated. I personally plan to check for those environment variables during activation, a
nd if they are set then forcibly set the environment via WWBD.

Is it possible to add some telemetry to check these so we know how many users activate and launch vscode.
At one point we (Jupyter ext) were supposed to do this to figure out how often users do this, which could in turn be an indication of why kernels fail to work.

[brettcannon]

Is it possible to add some telemetry to check these so we know how many users activate and launch vscode.

Probably could, but I honestly don't see any reason not to do this; doing it in WWBD just helps get it out faster and test it without breaking people's workflow. I would expect we would do this as an experiment in the core extension rather than worry about telemetry of potential use since this shouldn't be too expensive to do.

[greazer]

Woot! Love the idea of trying it out in WWBD.

Ensure that the activated environment is only applicable during the lifetime of that VS Code session (across reloads of course)

I don't quite follow here. You say the chosen environment "is only applicable during the lifetime of that ... session", but you always say that it should persist "across reloads of course". To me that seems contradictory. Are you suggesting that the selection of the activated environment is ephemeral and forgotten once VS Code is quit?

Maybe this isn't an issue. My thought was that if the user starts VS Code from an activated environment, it should always be that selected Python environment. However, it doesn't "stick" such that if they launch VS Code from a shortcut on the desktop that that last chosen environment will be used.

This is the kicker... Don't allow the user to change the active environment at all in this mode.

I don't think this can be a mode; it's all or nothing. So either we say you must launch VS Code from a shell with an activated environment (which isn't possible for those that launch from a shortcut on their desktop), or you have the option to potentially undue your mistake of using the wrong environment in your shell for your workspace. It also isn't applicable across workloads to lock you into what you launched with: if I have multiple environments set up for different Python versions I shouldn't have to quit VS Code just to change my environment.

I'm not totally following here. I think what you're saying is that we cannot lock the user's environment if they started from that environment because they have the ability to change the selected environment once VS Code is started. Right. And that's my point. We can know if a user started with an activated environment (other than "base" possibly), and if they did, then disable/hide/error out the commands that allow the user to change it. Is this at least technically possible to pull off? If not, then the discussion can end. But it seems possible and is at least an idea to play around with. :) Assuming it's possible, if a user wants to use another environment for a VS Code instance started this way, then they'd have to shut down that instance. I know it sounds crazy, but this is exactly how Jupyter works today. I'm not saying we just have to copy Jupyter. What I'm saying is that it can provide a simplified and intuitive experience for many.

For users that start from a shortcut, the limitation wouldn't exist. They'd be free to choose an environment just how they do today.

[brettcannon]

My thought was that if the user starts VS Code from an activated environment, it should always be that selected Python environment. However, it doesn't "stick" such that if they launch VS Code from a shortcut on the desktop that that last chosen environment will be used.

If WWBD does the setting, then that selection will persist for that workspace until it's changed.

I think what you're saying is that we cannot lock the user's environment if they started from that environment because they have the ability to change the selected environment once VS Code is started. Right.

Not "because they have the ability" as in "it's functionality we already provide," but more that it's a valid use-case to want to change your environment. For instance, I know library developers who need to test against multiple Python versions and so have multiple environments set up. If they happen to launch from an activated environment for Python 3.10, run e.g. Nox to test against all the Python versions installed, and get a failure for Python 3.7, I don't want to force them to quit VS Code just to switch to the 3.7 environment to try and fix their issue.

We can know if a user started with an activated environment (other than "base" possibly), and if they did, then disable/hide/error out the commands that allow the user to change it. Is this at least technically possible to pull off?

With enough blood, sweat, and tears, sure. 😉 We would have to store some global state upon execution as to how the current environment was selected and then do something to either prevent or error out when trying to change the environment.

is at least an idea to play around with. :) Assuming it's possible

Do we have telemetry showing that this is a concern? It's going to take away a use-case, so I would be hesitant to do a potentially deep change to guard all potential triggers of the quick-pick for environments unless this was data-driven.

I know it sounds crazy, but this is exactly how Jupyter works today.

Jupyter also doesn't launch VS Code today. 😉

In all seriousness, this does get a bit philosophical very quickly as to whether we want to match the typical Jupyter workflow to this extent? I think the issue here is while you could argue like Jim is that Jupyter users may like this footgun-avoidance feature, that's the only group who may want this. So this would then become a conda-only situation, but it's really a "conda user using Jupyter" situation which is even narrower and harder to identify based on intent until they launch the Jupyter extension.

But maybe that's the potential feature if we choose to pursue this? If you launch the Jupyter extension we lock you out from changing your environment. But I would definitely want to drop Jupyter as a soft dependency first in that case to avoid accidental triggering of this feature.

[karrtikr]

It's done. Closing as in favor of #10668.