Repository navigation
When VS Code is launched from a terminal with an activated environment, select it #18178
Closed as not planned
Description
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:
- Ignore the one you launched VS Code under?
- Automatically select the activated one?
- Prompt to see whether you want to keep your previously selected environment or switch to the activated one?
Activity
paulacamargo25 commentedon Dec 15, 2021
The team discuss this and we decided that we will select the activated environment if there is no environment explicitly selected by User.
5 remaining items
karrtikr commentedon Apr 29, 2022
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 commentedon Apr 29, 2022
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.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 commentedon May 2, 2022
I plan to test this out in WWBD.
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?
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.
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 commentedon May 3, 2022
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 commentedon May 3, 2022
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 commentedon May 3, 2022
Woot! Love the idea of trying it out in WWBD.
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.
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 commentedon May 4, 2022
If WWBD does the setting, then that selection will persist for that workspace until it's changed.
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.
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.
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.
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 commentedon Mar 3, 2023
It's done. Closing as in favor of #10668.