Repository navigation
Pipenv environment is not activated using pipenv shell #12011
Description
Activity
It would also fix a broken pipenv activation if you move your project.
Reacted by Jakub BláhaWe'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?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?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.
SayC:/Users/jakub/.virtualenvs/Fiverr_28-MrJNCoYT/Scripts/python.exeispython1
SayC:/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.
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.
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 ;)
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.Perhaps #8870 could also help as a workaround. Please upvote, helps bump the priority.
Reacted by Jakub Bláha and jakubblaha-idsShould be fixed along with #12020, but let's keep this open until then.
Reacted by George TantirasJakub 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.- changed the title
[-]Pipenv environment is not activated when opening a new GitBash terminal[/-][+]Pipenv environment is not activated using pipenv shell[/+]on Mar 18, 2021 - locked and limited conversation to collaborators
on Mar 22, 2021
Environment data
python.languageServersetting: MicrosoftExpected 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:
What I suggest
Pipenv provides a really useful layer of abstraction and one of it's features is the
pipenv shellcommand, 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 shellinstead of directly activating the venv.