Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pip install -e doesn't uninstall existing versions #1548

Closed
msabramo opened this issue Feb 10, 2014 · 1 comment
Closed

pip install -e doesn't uninstall existing versions #1548

msabramo opened this issue Feb 10, 2014 · 1 comment
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@msabramo
Copy link
Contributor

This has been an annoyance for me and my colleagues and I think I have a one line fix, but I figured that there is a good chance that this a known issue and that it's been discussed before and there's some reason not to change it.

A pip install of one version of a package will typically cause the previously installed version to be uninstalled, so there is only one version installed at a time.

If one installs a regular package from PyPI and then installs an editable package from git or from a local directory (e.g.: pip install -e .), then the former package does NOT get uninstalled and you have two versions installed (even though pip freeze will only show one). In this weird state, sometimes the older package will get picked up and a single pip uninstall is not enough to clean up. You have to do a not obvious pip uninstall TWICE to completely remove the package.

Example

$ virtualenv pip_test
...
$ cd pip_test && source bin/activate
$ pip install requests==0.5.0
...
Successfully installed requests
Cleaning up...
$ python -c 'import requests; print(requests.__version__)'
0.5.0
$ pip install -e ~/dev/git-repos/requests/
Obtaining file:///Users/marca/dev/git-repos/requests
  Running setup.py egg_info for package from file:///Users/marca/dev/git-repos/requests

Installing collected packages: requests
  Running setup.py develop for requests

    Creating /private/tmp/pip_test/lib/python2.7/site-packages/requests.egg-link (link to .)
    Adding requests 2.0.1 to easy-install.pth file

    Installed /Users/marca/dev/git-repos/requests
Successfully installed requests
Cleaning up...
$ python -c 'import requests; print(requests); print(requests.__version__)'
<module 'requests' from '/Users/marca/dev/git-repos/requests/requests/__init__.pyc'>
2.0.1
$ pip uninstall requests
Uninstalling requests:
  /private/tmp/pip_test/lib/python2.7/site-packages/requests.egg-link
Proceed (y/n)? y
  Successfully uninstalled requests
$ python -c 'import requests; print(requests); print(requests.__version__)'
<module 'requests' from '/private/tmp/pip_test/lib/python2.7/site-packages/requests/__init__.pyc'>
0.5.0
$ pip uninstall requests
Uninstalling requests:
  /private/tmp/pip_test/lib/python2.7/site-packages/requests-0.5.0-py2.7.egg-info
  /private/tmp/pip_test/lib/python2.7/site-packages/requests/__init__.py
  /private/tmp/pip_test/lib/python2.7/site-packages/requests/__init__.pyc
...
Proceed (y/n)? y
  Successfully uninstalled requests

Any reason NOT to have pip install -e check for previously installed versions and uninstall them?

msabramo added a commit to msabramo/pip that referenced this issue Feb 10, 2014
by adding an additional call to `requirement.check_if_exists()` to
RequirementSet.install

Fixes pypaGH-1548
msabramo added a commit to msabramo/pip that referenced this issue Feb 10, 2014
by adding an additional call to `requirement.check_if_exists()` to
RequirementSet.install

Fixes pypaGH-1548
@minrk
Copy link
Contributor

minrk commented Aug 10, 2015

I think this is because pip install -e is mostly a wrapper around setup.py develop, which does all the unpleasant setuptools machinery that pip otherwise avoids during a regular install. It would seem that the right fix for this one is for pip to do to setuptools develop what it has already done to setuptools install. Among the unpleasant side effects of this is the use of easy_install.pth, which causes all sorts of problems.

xavfernandez added a commit to xavfernandez/pip that referenced this issue Aug 5, 2016
But only when pip has collected the editable package's metadata.

closes pypa#1548
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 4, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

No branches or pull requests

2 participants