Automatically select interpreter when VIRTUAL_ENV is set

[brettcannon]

When a virtual environment is activated the VIRTUAL_ENV environment variable is set to the location of the virtual environment. We could pick up on this and use it as the implicit value of python.pythonPath when that setting has not already been set.

[alexwhittemore]

Thanks for pointing me here! Sorry I didn't catch the diversion when you mentioned it in an earlier comment over on that other issue.

I can accept that this just doesn't actually work the way I thought, but what I'm confused about now is why I didn't know that. That is, why does this work in windows exactly this way when using virtualenvwrapper-powershell? And why did I think it worked this way already on my other/older mac? [I don't really expect you to answer that second question; I just need to go look at how that machine is set up. Maybe it doesn't and never did and I've just been spoiled by it working out of the box on windows this whole time and didn't even realize.]

[brettcannon]

@alexwhittemore best I can think of is PowerShell is passing the environment down differently and we are just picking things up on PATH like we always have while on your other system it just isn't quite falling through the same way.

[alexwhittemore]

Hold on, this is even weirder than I realized... Or maybe exactly as weird.

Read this stream of consciousness if you like, but you can probably just skip to the bottom.

Background: used to develop on Mac, switched to a Surface Pro for the last 1.5yrs or so, and just bought a new mac. The OLD mac, where I thought this always did what I want but maybe was mistaken, actually exists on a backup because I had to do a "temporary" fresh install on that hardware. So I don't have ready access to that environment at the moment, and I'm beginning to think it probably never actually had code on it anyway. The current environment on old mac behaves exactly as it's behaving on new mac.

But I noticed an interesting thing.

On Windows:
Pre-activate: "Path" is normal, and python refers to Users\alexw\scoop\shims\python.ps1, my scoop-installed systemwide python.
And of course, when I code . and open a .py, my interpreter in the bottom right is set to that python above. And when I open a terminal and pip list, I get all the packages from the system-wide environemnt. And when I open developer console and process.env, "Path" is the same as it was back at the powershell, my normal system path.

Post-workon my_env: "Path" gets prepended with my virtualenv, "python" is the one in my virtualenv, and when I open a .py in code, the interpreter is properly set to the one in my virtualenv. "pip list" in a terminal window shows the virtualenv packages, and "Get-ChildItem Env:" in that terminal shows "Path" has the virtualenv prepended. And just a sanity check, "process.env" shows the same "Path" with the virtualenv prepended. In other words, the electron environment is the same as the terminal I launched from.

On mac:
The interesing thing is, this isn't completely untrue on mac-
Pre-activate: same same - systemwide path variable, default python, default package list, both at terminal and in the launched vscode, of course.
post-workon: When I run (foobarenv3x) $ code ., code comes up and with a python file open, the interpreter reflected in the bottom left actually IS the virtualenv interpreter. For example, mine right now says "Python 3.7.0 (virtualenv)". AND "process.env" shows the virtualenv-ed path: "PATH
:
"/Users/alexw/.virtualenvs/foobarenv3x/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"" But the terminals I open don't reflect the same environment.

It's as if the virtualenv actually IS getting adopted, but the vscode-python processes don't actually use it for whatever reason. For example, linting. The currently activated virtual environment must have pylint installed, or you get the "pylint is not installed" message when saving a .py (settings otherwise notwithstanding). So at the terminal, I (foobarenv3x) $ pip install pylint and re-launch vscode from that terminal window.
Wait, no, that works totally.

THIS IS IT!
The issue is that Code adopts the environment variables of the terminal it was launched from, EXACTLY as I'd expect. BUT new child terminals DON'T, which I think must specifically be a bug. This made me THINK the environment wasn't getting adopted, because I'd click "install pylint" then that command would go about it's business in the default-opened VSCode terminal window, which WASN'T USING THE LAUNCHED "PATH". So I'd click "install pylint," and it'd install to the system global python environment, then of course not work next time I launched Code.

So, TL;DR, the actual bug here is that the "Open new terminal" and "Python: create terminal" commands aren't spawning terminals with the same PATH that code is using. And that breaks python plugin functions like "install linter" etc etc.

EDIT: Opened issue #2333 since this seems like its own, independent bug.

[brettcannon]

@alexwhittemore all of this is actually known because we are executing processes through a system call that isn't inheriting the environment or in a shell. I've opened #2363 to look into changing how this works.

[alexwhittemore]

You might have just gone above my head a little; I don't really understand the difference. But it does appear to be the case that it's not quite accurate, at least not in the cases that a user would recognize. Namely, when I put in place my goofy hack from the latest comment at #2333, it all "Just Works" the way I expect/think it should. It seems to me like re-activating a detected virtualenv in ~/.bash_profile wouldn't work so effectively if what you're saying is true. Does that make any sense?

[brettcannon]

I get it, but I think we might be talking about different things in terms of how/where code is being executed.