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]

@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]

@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.

[karrtikr]

I understand. I was talking about what a user is technically allowed to do. He could use pipenv environment created for some other workspace as interpreter for this one.

then it isn't smart to use pipenv at all

You'll be surprised at what our 40M userbase can attempt to do ;)

[JakubBlaha]

I understand now. I guess there should be an option of whether to use the current method of environment activation, which may be faster or the more reliable option, the pipenv shell command.

[karrtikr]

Perhaps #8870 could also help as a workaround. Please upvote, helps bump the priority.

[karrtikr]

Should be fixed along with #12020, but let's keep this open until then.

[karrtikr]

@JakubBlaha Actually I found out we have had some issues with using pipenv shell, #4404 due to which we removed activating using that command. It's related to pipenv shell command being slow. So we cannot bring it back as is.

Perhaps we can use pipenv run for scenarios in #4404 instead, and use pipenv shell in other cases. Still need further investigation.