pipenv should prompt before removing existing an existing virtualenv unceremoniously.

[PaulHobbs]

https://github.com/kennethreitz/pipenv/blob/6edfc896729bf1ea09338d935dddf23a372f37c1/pipenv/cli.py#L572

I had a large virtualenv that I used for developing various projects. When I started playing around with pipenv, it immediately deleted it.

Don't do that without asking, please.

[nateprewitt]

@PaulHobbs this should only run if you pass parameters to create a new environment. We have --two/--three/--python listed in the help messages, README and basic documentation as being destructive commands and only used to create new projects.

Did you use another command combination that resulted in your virtualenv being overwritten? I'm sympathetic to have additional warnings but also want to approach this pragmatically. Most users wouldn't expect/want a command like rm to prompt you every time it's used though because it creates an irritating experience.

[PaulHobbs]

Why does a CLI command for creating a virtualenv for a project destroy a virtualenv completely unrelated to the project? To me the only sane thing to do would be to deactivate, create the environment, then re-activate the new environment.

Having it documented in the help is not enough - it could document "calls rm -rf on ~/.virtualenvs/*", and it would still be the wrong thing for it to do.

The whole point is that "project.virtualenv_location" is set to the path of a virtualenv that not associated with the project, it's just a virtualenv I happened to have activated previously. It's never appropriate to delete it.

[nateprewitt]

Ah yeah, that's a feature Kenneth added recently. There was a demand for using the currently activated environment as the working environment. Using pipenv with an active environment will use that rather than spawning a new one for the project directory. We also have a message that informs the user that this is happening, albeit after the process has already been initiated.

So, I don't have an issue placing a prompt here since this is less traveled path for environment creation. This is a less obvious stumbling block if the user feels the need to activate a virtualenv.

[techalchemy]

Possibly we should consider virtualenvs we did not create to be 'unmanaged' and never delete them with pipenv --<anything>

[nateprewitt]

@techalchemy we don't have a way to keep track of that. We can make assumptions but that doesn't really solve the problem and will make the activated venv experience worse.

I think the warning prompt is probably the best we can do here.

[techalchemy]

@nateprewitt we can sort of keep track of it, if it doesn’t follow our naming conventions, $PIPENV_IGNORE_VIRTUALENVS isn’t set, and we are still in an active virtualenv we can assume we don’t manage it, can’t we? I mean, if it’s one we wouldn’t otherwise find, we couldn’t possibly manage it

[techalchemy]

With the caveat I always have when I write strong statements but is never conveyed well via text— that I am prepared to be wrong either for technical or pragmatic reasons

[nateprewitt]

@techalchemy or if it's in the project with PIPENV_VENV_IN_PROJECT, or if they've set WORK_ON, or if they use an auto-activate setup, or something else we haven't thought to account for yet. Changes like that without a clear way to determine how they work end up becoming difficult to maintain and then you end up with more bandaid code.

Leaving a warning prompt is a minimal change providing a safeguard, but I don't really like that either because it penalizes people using that workflow regularly. The fix for that would be to have them set PIPENV_YES which isn't great but workable.

[techalchemy]

Hm, right, because Project.virtualenv_location just tells you where the virtualenv is, unlike Project.virtualenv_name or whatever the hashing function is

[gauravssnl]

pipenv deleted my virtualenv 'py36' which I had created with pyenv where I had installed many modules which I use often.Some of the modules like cv2(OpenCV),WxPython,etc. , I had built them manually for my system and it requires time. I think pipenv should ask for confirmation before such things.I have no requirements.txt file left so that I can install all those modules of virtualenv 'py36' again .I made a mistake by using it with pyenv .I really did not like this.

[techalchemy]

@gauravssnl I am not that experienced with whatever you are doing with pyenv. Can you explain your configuration -- it appears that you have your virtualenvs managed by pyenv directly and they are appearing as python versions when you run pyenv versions? What was the configuration there, are you running pyenv inside a virtualenv, and then pipenv installed inside that virtualenv as well? I'm confused about how your entire pyenv python mapping broke

Apart from that, pipenv is designed to work with a normal pyenv configuration (I use it every day). The issue here is more that you installed and used pipenv inside of a virtualenv that it didn't manage, and when you used it you explicitly told it a python version (by passing --two or --three). When you do this you are telling pipenv to forcibly override the environment python version with the one you are providing as an argument, which naturally requires a full wipe. I think we want to add a more explicit warning for this use case but as the discussion above describes there are other issues with that potentially.

I'm sorry about your virtualenv getting wiped, that really does suck. I want to improve the experience of working with pipenv to avoid things like this, but first I do need to understand abit more about your environment and how pyenv plays into all of this so that we can catch this situation and handle it properly

[gauravssnl]

@PaulHobbs I had created virtualenv by using pyenv by using the command: 'pyenv virtualenv 3.6.1 py36' and the virtualenv 'py36' was being managed by pyenv .I installed pipenv by using pip and when I tried 'pipenv --three' command , pipenv wiped my virtualenv 'py36' (which was not created by pipenv but by pyenv) even without asking for confirmation.I really don't understand this and don't like this.
If virtualenv is created by pipenv then only it should delete it without confirmation .Otherwise ,it should give warning first before deleting virtualenv created by pyenv and ask for confirmation before deleting the virtualenv .

[PaulHobbs]

@gauravssnl, agreed, I ran into the same frustrations.

As for solutions, instead of relying on naming conventions, could pipenv leave behind a cookie file in the virtualenv, say, pipenv.json with some basic metadata? Then pipenv could check for that file before deleting the virtualenv.

[gauravssnl]

Well,that is possible.But asking for confirmation before deleting virtualenv created by other tools is not a bad idea.If user agrees,then delete it. @PaulHobbs

[techalchemy]

@gauravssnl I am the one who asked for follow up info, but we have already discussed prompting the user in other comments in this issue. I don’t know anything about the pyenv virtualenv addon which presents a virtualenv as a pyenv version. I see that as problematic potentially but I am on vacation this weekend so I won’t have a chance to look at this for a few days

/cc @nateprewitt

[PaulHobbs]

Why was this closed?

[darkfeline]

Note: This was added in 4e3548f1cb743574676230cb0da5f0f3d73d0968