Running pipenv destroys a virtual environment it didn't create or manage.

Running pipenv --two where pipenv was installed in a separate existing virtual environment results in pipenv destroying the existing virtual environment instead of just using it.

$ cd /tmp

$ virtualenv pipenvtest
New python executable in /private/tmp/pipenvtest/bin/python
Installing setuptools, pip, wheel...done.

$ cd /tmp/pipenvtest/

$ source bin/activate

(pipenvtest) $ pip install pipenv
Collecting pipenv
  Downloading pipenv-8.2.6.tar.gz (3.7MB)
    100% |████████████████████████████████| 3.7MB 287kB/s
...
(pipenvtest) $ pipenv --two
Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project.
Virtualenv already exists!
Removing existing virtualenv…
You are attempting to re-create a virtualenv that Pipenv did not create. Aborting.

(pipenvtest) $ pwd
/tmp/pipenvtest

(pipenvtest) $ ls -als
total 0
0 drwxr-xr-x  2 graham  wheel   68  3 Oct 13:09 .
0 drwxrwxrwt  6 root    wheel  204  3 Oct 13:09 ..

The expectation is that the message:

Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project.

would indicate that pipenv would use the existing virtual environment as is and not try and delete it, but that wasn’t the case.

It seems to leave it alone if you don’t run pipenv --two and instead just go straight to pipenv install.

So with Pipfile containing:

[packages]
antigravity = "*"

and the existing virtual environment activated, get:

(pipenvtest) grumpy-at-home:pipenvtest graham$ pipenv install
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (0aecac)!
Installing dependencies from Pipfile.lock (0aecac)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 1/1 — 00:00:00

That it goes off and deletes the existing virtual environment which it didn’t create in the first place is not what one would expect. It could also cause loss of files, if it so happened that as a part of a build system for a deployment, application specific files were added into other sub directories of the virtual environment for convenience.

[Hunter-Github]

Sorry, guys and gals. Pipenv destroyed my virtualenv and I’m not going to use it anytime soon. This is so mean. (Yeah, been lured into pipenv by high acclaim on HN. Won’t do that again.)

Okay, here goes the technical information:

pipenv-9.0.3

> pipenv --python 3.5

Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project.
Virtualenv already exists!
Remove existing virtualenv? [Y/n]: y
Removing existing virtualenv…
You are attempting to re-create a virtualenv that Pipenv did not create. Aborting.

This is basic. You rm -rf other people’s hard work and Abort after that.

[danieljacobs1]

Shouldn’t the same pattern be applied in the Python world with pipenv? (even more so as it seems this tool has the potential to become the de-facto tool to managing virtual envs and dependencies)

I assumed it was bit by looking at this conversation it seems it isn’t.

I meant specifically if you didn’t have admin access to your (Linux) work station, and therefore wouldn’t be able to install it globally. I’m sure pipenv will make it into the various Linux distribution repos soon enough (if it isn’t there already), in which case you’ll have that global installation.

Even if I do have root access to a machine, I tend to avoid sudo pip install. The reason for this is that the system python installation is managed by a different package manager (i.e. yum, apt-get etc) and using sudo pip install could tread on the other package manager’s toes. That could leave your system in an inconsistent state and potentially could break the system’s package manager.

Additionally, the system python is often used for various system utilities (e.g. the printer console etc). You could easily break these tools by sudo pip install-ing a newer version of something from PyPI that is incompatible with everything else.

Lastly, you might want to try/test the latest version of pipenv, and as some Linux distros are very conservative with updates (e.g. Debian), the separate-venv trick is the ideal way.