Pipenv environment is not activated using pipenv shell

[brettcannon]

Make sure to handle #4203 and #4245 if and when bringing pipenv shell back.

Potential solution:

Use new VSC API (proposed API at the time of writing this) to check what information has been written out into terminal before sending other commands.

See here microsoft/vscode#67693 (comment)

Discussed in #15745

^{Originally posted by JakubBlaha May 27, 2020}

Environment data

• VS Code version: 1.45.1
• Extension version (available under the Extensions sidebar): 2020.5.80290
• OS and version: Windows 10, build 18363
• Python version (& distribution if applicable, e.g. Anaconda): 3.7.7, python.org
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): pipenv
• Value of the python.languageServer setting: Microsoft

Expected behaviour

When opening a new git bash terminal, the pipenv environment is properly activated.

Actual behaviour

jakub@LAPTOP-6R3A0N4R MINGW64 /d/Fiverr_28 (master)
$ source C:/Users/jakub/.virtualenvs/Fiverr_28-MrJNCoYT/Scripts/activate
(Fiverr_28)

which does not activate the environment properly in GitBash

Developer note: This is actually because of other issues we had with pipenv shell, see #4203

Steps to reproduce:

1. Set the default integrated terminal to GitBash
2. Create new Pipenv environment
3. Set the project interpreter to the adequate venv
4. Open a new integrated terminal

What I suggest

Pipenv provides a really useful layer of abstraction and one of it's features is the pipenv shell command, which is not being used in this case. Using this command instead of directly running the activation script would resolve this issue.

The issue #2559 would also be resolved by using pipenv shell instead of directly activating the venv.

[brettcannon]

Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 5 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

[alper]

👍🏼

[brettcannon]

Thank you to everyone who upvoted this issue! Since the community showed interest in this feature request we will leave this issue open as something to consider implementing at some point in the future.

We do encourage people to continue 👍 this issue as it helps us prioritize our work based on what the community seems to want the most.

[karrtikr]

Handle #4203 #4245 if and when bringing pipenv shell back.

[g1augusto]

Hi there,

just dropped by and wanted you to know I am in the same situation, pipenv shell is not called even if it's identified by VScode.

I hope you can get it to work together, Thanks a lot!

[adam4813]

I think a good way to go about this would be to just provide a setting to indicate how the virtual environment should be loaded/activated e.g. a dropdown to pick from "activate.ps1", "pipenv shell", etc. This gives the freedom to use what you need, but can also give that safety net if auto-detection fails.

[Arcitec]

What is the reason for wanting pipenv shell? It sounds like a bug in GitBash fake-shell.

I'm using ZSH on Linux. and my venv is being activated via the /path/to/venv/bin/activate script, and my terminal works perfectly and uses the correct pipenv python interpreter and installed site-packages.

Calling python --version inside the terminal shows the version used by that venv. And all modules from that environment are usable by the scripts.

The only thing the bin/activate script does is modify the PATH and some other variables to make commands like python pick the correct location, and some virtualenv environment variables that tell Python itself which site-packages folder to use.

If GitBash doesn't support modifying PATH and adding some other env variables then I don't know how GitBash can pretend to even be a shell...

Edit: Actually, I can give you a strong guess about what's wrong...

The bin/activate script is written for Linux and contains the absolute path of your virtual environment, such as VIRTUAL_ENV='/home/foobar/.local/share/virtualenvs/yourproject-o3WQlgT4'. This path is not legal inside GitBash, which maps Windows C: drive as /c/stuff/here. There is nothing you can do about that.

I suppose that pipenv shell has alternative activation code to fix this problem on Windows.

But VSCode cannot use pipenv shell because that broke Debugging of python programs, as described here: #4203

Perhaps pipenv can tweak the generation of bin/activate on Windows to include GitBash compatible code, if they think that such a change makes sense.

My heart goes out to you Windows developers. :P You may wanna just get WSL to run VSCode inside that instead. I hear it can run GUI apps these days. Or install Linux. I recommend Fedora, it's clean, stable and easy to use and is the distro chosen by Linus Torvalds and his whole family. It's a joy to use.

[adam4813]

My issues/reason is when using PowerShell and OhMyPosh, I have the venv info before the prompt and also within the OhMyPosh prompt as well. Either way works to activate under windows with debugging, it's just the prefix to the prompt that is annoying and cannot be fixed.

[Arcitec]

@adam4813 Hmm, so if you run the current Python extension (which uses the bin/activate script) with PowerShell, it's activated correctly?

The reason why you get a dual prompt is that the activate-script edits the prompt (PS1 variable) and prepends the name of the venv before the normal prompt. Not sure what can be done about that... Perhaps add an alias to your powershell scripts which resets the prompt to the normal one...? And manually run it in the terminal once per project, whenever the issue arises.

Edit: Another idea may be to see if your can turn off "display venv name" in your OhMyPosh configuration to avoid the dual names that way.

[brettcannon]

vscode-python/src/client/common/terminal/environmentActivationProviders/pipEnvActivationProvider.ts

Line 54 in 1186432

return [`${execName.fileToCommandArgumentForPythonExt()} shell`];

shows that we are using pipenv shell at this point, so closing as fixed.

[karrtikr]

@brettcannon The code is there but actually it is disabled in the line above:

vscode-python/src/client/common/terminal/environmentActivationProviders/pipEnvActivationProvider.ts

Lines 27 to 29 in 1186432

	public isShellSupported(): boolean {
	return false;
	}

So we end up not using pipenv shell, hence reopening.

[karrtikr]

We have a new activation mechanism #11039 which does not require executing any script, give it a try:

• Use latest version of VS Code and Python extension
• Add the following to User settings and reload window:

  "python.experiments.optInto": ["pythonTerminalEnvVarActivation"]

Btw note, Python extension does not support Gitbash currently.