Repository navigation
Pipenv environment is not activated using pipenv shell #12011
Description
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.languageServersetting: 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:
- Set the default integrated terminal to GitBash
- Create new Pipenv environment
- Set the project interpreter to the adequate venv
- 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.
Activity
bephinix commentedon May 27, 2020
It would also fix a broken pipenv activation if you move your project.
karrtikr commentedon May 28, 2020
We've confirmed this issue, thanks. Although the activation works fine for me, it's better to use
pipenv shellwhen we already detect it's a pipenv environment.That being said, what if there're multiple pipenv environments in
.virtualenvsdirectory. Willpipenv shellautomatically handle which one to activate for the workspace folder?JakubBlaha commentedon May 28, 2020
Yes.
pipenvdoes handle this. This is the whole purpose ofpipenv, 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 commentedon May 29, 2020
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(sayw1) can select any pipenv environment within the directoryC:/Users/jakub/.virtualenvs.Say
C:/Users/jakub/.virtualenvs/Fiverr_28-MrJNCoYT/Scripts/python.exeispython1Say
C:/Users/jakub/.virtualenvs/<some other environment>/Scripts/python.exeispython2Suppose for
w1, user selectspython2as an interpreter. But if we sendpipenv shellcommand when a new terminal is created,python1will be activated instead.So the logic will not be as straightforward as simply sending
pipenv shellas activation command.Although I think in most cases, users only use one pipenv environment per workspace, but we can never know.
JakubBlaha commentedon May 29, 2020
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.
karrtikr commentedon May 29, 2020
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.
You'll be surprised at what our 40M userbase can attempt to do ;)
JakubBlaha commentedon May 29, 2020
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 shellcommand.karrtikr commentedon May 30, 2020
Perhaps #8870 could also help as a workaround. Please upvote, helps bump the priority.
karrtikr commentedon Nov 30, 2020
Should be fixed along with #12020, but let's keep this open until then.
karrtikr commentedon Feb 3, 2021
Jakub Bláha (@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 topipenv shellcommand being slow. So we cannot bring it back as is.Perhaps we can use
pipenv runfor scenarios in #4404 instead, and usepipenv shellin other cases. Still need further investigation.[-]Pipenv environment is not activated when opening a new GitBash terminal[/-][+]Pipenv environment is not activated using pipenv shell[/+]