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

[GrahamDumpleton]

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.

[kennethreitz42]

Do not do that.

[kennethreitz42]

This has been fixed in recent releases.

[kennethreitz42]

ah, --rm was fixed, but not this.

[danieljacobs1]

I've also seen this while learning how to use pipenv.

I think a common use case will be to install pipenv into one venv and run it to manage others, particularly if you don't have admin access to your work station. This is how I was trying to use pipenv. Maybe this is not the intended way?

[uranusjr]

@danieljacobs1 Your setup is more or less how the “fancy” installation works, and should work perfectly as long as you don’t activate the virtualenv containing Pipenv. If you refrain from using Pipsi, I would recommend you add the bin directory of the virtualenv containing Pipenv to your PATH, or use command aliases to launch Pipenv without activating the virtualenv.

[kennethreitz42]

actually, this should be fixed in the latest release.

[walterdolce]

I think a common use case will be to install pipenv into one venv and run it to manage others

In the PHP world, I have only seen people having a global _composer_ installation and use it everywhere. In the Ruby world, I have _usually_ seen people having a global _bundler_ installation and use just that. Same goes for npm.

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.

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

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

[remram44]

Yes I seem to also be affected by this. Of course I have pipenv installed in a virtualenv, and though it did not obliterate anything yet, it does act on that environment instead of creating new ones.

Calling env/bin/pipenv without activating the env works, but it is really easy to forget, and no one is gonna assume it is how it works, meaning they will do it wrong until they Google for this ticket.

I suggest a workaround be shown with the "courtesy notice". It is also very likely that no one actually means to use pipenv to manage a non-pipenv environment, so maybe that "courtesy notice" should be made into an error that stops it from destroying manually-created environments.

[uranusjr]

@remram44 I would set something like alias pipenv=env/bin/pipenv in the profile. Still need to remember to deactivate first though. Pull requests are also highly welcomed!