Pipenv environment is not activated using pipenv shell

[JakubBlaha]

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

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.

[bephinix]

It would also fix a broken pipenv activation if you move your project.

[karrtikr]

We've confirmed this issue, thanks. Although the activation works fine for me, it's better to use pipenv shell when we already detect it's a pipenv environment.

That being said, what if there're multiple pipenv environments in .virtualenvs directory. Will pipenv shell automatically handle which one to activate for the workspace folder?

[JakubBlaha]

Yes. pipenv does handle this. This is the whole purpose of pipenv, to make the experience more transparent. That being said, I am not sure what your doubt here is. Perhaps I got the meaning of your comment wrong?

[karrtikr]

Jakub Bláha (@JakubBlaha) The problem I see with this is that, technically, there can multiple pipenv environments a workspace folder can select. For instance,

Workspace folder /d/Fiverr_28 (say w1) can select any pipenv environment within the directory C:/Users/jakub/.virtualenvs.
Say C:/Users/jakub/.virtualenvs/Fiverr_28-MrJNCoYT/Scripts/python.exe is python1
Say C:/Users/jakub/.virtualenvs/<some other environment>/Scripts/python.exe is python2

Suppose for w1, user selects python2 as an interpreter. But if we send pipenv shell command when a new terminal is created, python1 will be activated instead.

So the logic will not be as straightforward as simply sending pipenv shell as activation command.

Although I think in most cases, users only use one pipenv environment per workspace, but we can never know.

[JakubBlaha]

Kartik Raj (@karrtikr) As from my understanding, pipenv is intended to be used with a single virtual environment and does not support creating multiple environments for a single workspace. Pipenv would refuse to create multiple environments for a single project. If a user needs to have multiple environments assigned to a single workspace, then it isn't smart to use pipenv at all, venv should be rather used.