Pipenv ignores active environment and creates new virtualenv anyway

As recently as Pipenv v3.3.6, I manually created my own virtual environment, installed Pipenv into it, and used Pipenv to manage project packages within that already-active virtual environment.

But since then there seems to have been a change that disrupts that workflow, and now Pipenv appears to ignore the active virtual environment and insists on creating its own virtual environment with an appended hash.

Steps to reproduce

> fish --version
fish, version 2.5.0

> echo $WORKON_HOME
/Users/me/virtualenvs

> vf new -p python3 foo  # manual creation of `foo` virtual environment

> (foo) echo $VIRTUAL_ENV
/Users/me/virtualenvs/foo

> (foo) pip install pipenv

> (foo) pipenv --version
pipenv, version 3.5.4

> (foo) pipenv install django==1.11rc1
Creating a Pipfile for this project...
Creating a virtualenv for this project...

Expected result

Pipenv would use the currently-active virtual environment.

Observed result

Pipenv ignores the currently-active virtual environment and creates a new environment, as seen above.

Additional notes

I sincerely hope this is merely a bug, and that the answer to this is not, “Virtualenv is behaving as intended.” I say this because (1) Pipenv supported this use case last month, and (2) I believe that Pipenv should support this use case: namely, installing Pipenv into a virtual environment, installing packages into that already-active virtual environment, and not insisting on creating its own virtual environment. I suspect this was introduced in a81197d, but that’s just a guess.

In addition to other problems, this change breaks automatic linking of projects and virtual environments based on identical naming conventions. Up until now, I have always been able to workon foo, which automatically activates the foo environment and switches to the ~/projects/foo directory. This change breaks that automation.

[ajmazurie]

Chiming in as well; I’m already using pyenv and direnv to automatically create virtual environments for Python interpreters, and pipenv would be a welcome addition if it could make use of these existing environments rather than creating new ones. Saying this, I realize what I really need is an updated version of pip that manages Pipfiles.

[justinmayer]

Hey @nateprewitt / @kennethreitz. Many thanks for your quick responses and insightful info.

I looked into the --system option, and assuming I understand correctly that it allows Pip to install into global system-wide site-packages, then I’m not sure that option adequately addresses the use case I described above. I never want Pipenv to install anything outside of a virtual environment, and it seems to me that this option might lead to that result if there is no currently-active virtual environment. Feel free to correct me if my understanding is wrong.

As @nateprewitt suggested, I think that adding an official feature that checks the $VIRTUAL_ENV variable and uses that as the “working” directory for pipenv commands sounds great. I understand the potential issue of folks not realizing they have a virtual environment active, but one of the many benefits of Pipenv is the ease with which the environment can be restored. 😊