Skip to content

Old version of package in build/ prevents upgrade #709

Closed
scjody opened this Issue Oct 22, 2012 · 13 comments

9 participants

@scjody
scjody commented Oct 22, 2012

If an old version of a package exists in build/ for whatever reason (possibly issue 413, possibly another issue), that version will be installed rather than the requested (or latest) version.

(pip_test)scjody@ailuropoda:~/pip_test$ grep ^Version build/Django/PKG-INFO 
Version: 1.4.1
(pip_test)scjody@ailuropoda:~/pip_test$ pip install Django==1.4.2
Downloading/unpacking Django==1.4.2
  Running setup.py egg_info for package Django

Installing collected packages: Django
  Running setup.py install for Django

    changing mode of /home/scjody/pip_test/bin/django-admin.py to 755
Successfully installed Django
Cleaning up...
(pip_test)scjody@ailuropoda:~/pip_test$ pip freeze |grep Django
Django==1.4.1
@scjody
scjody commented Oct 22, 2012

As a workaround, create a new temporary directory and set --build=/that/directory before running pip. If you're calling pip from Python code, you can do something like this:

import shutil
import tempdir
[...]
build_dir = tempfile.mkdtemp()
command = "bin/pip install --build=%s some-package" % build_dir
sh(command)
shutil.rmtree(build_dir)
@pnasrat
Python Packaging Authority member
pnasrat commented Oct 23, 2012

What version of pip did you test this with?

@scjody
scjody commented Oct 23, 2012

The output above is from pip 1.1, but it also happens with pip 1.2.1.

I've seen pip 1.2.1 warn you that it isn't installing the requested version, but that doesn't happen all the time (I can't get it to happen right now for example) and it's still pretty bad behaviour if you're calling pip from a script.

Here's what 1.2.1 is doing for me right now:

(pip_test)scjody@ailuropoda:~/pip_test$ pip --version
pip 1.2.1 from /home/scjody/pip_test/lib/python2.7/site-packages (python 2.7)
(pip_test)scjody@ailuropoda:~/pip_test$ pip install Django
Downloading/unpacking Django
  Running setup.py egg_info for package Django

Installing collected packages: Django
  Running setup.py install for Django
    changing mode of build/scripts-2.7/django-admin.py from 644 to 755

    changing mode of /home/scjody/pip_test/bin/django-admin.py to 755
Successfully installed Django
Cleaning up...
(pip_test)scjody@ailuropoda:~/pip_test$ pip freeze |grep Django
Django==1.4.1
@diranged
diranged commented Mar 8, 2013

We're seeing this issue with Pip 1.3.1 as well.. I've replicated it several times this morning. Manually clearing the build dir does fix it, but thats a really ugly step.

Any time you ask Pip for version XYZ of an app, it should always go out and look specifically for that version if it doesn't have it locally. It should not throw the message:

Requested kazoo==0.9, but installing version 1.0b1

@jimabramson

i just saw the same thing happen with pip 1.3.1 as well. was unable to downgrade a previously-installed, then uninstalled package.

Requested pika==0.9.8, but installing version 0.9.9

the same workaround described above was effective.

@greatestape

Any time you ask Pip for version XYZ of an app, it should always go out and look specifically for that version if it doesn't have it locally.

Agreed! Oh generous pip developers, please fix this! pip is great, but this is crumby.

@qwcode
Python Packaging Authority member
qwcode commented Mar 11, 2013

pull #712 has a solution, but I think the consensus was to trim it out part of it.
will post again soon with the non-controversial part.

@fernandogrd

Quite of the same problem here:
If I do
pip install -U djangorestframework or
pip install djangorestframework==2.2.4 or
pip install djangorestframework

I get this, even if I uninstalled it first, the only thing that worked was remove djangorestframework from build directory.

One thing to highlight is that I had installed it from git repository the first time.

$ pip install -U djangorestframework
Downloading/unpacking djangorestframework==2.2.4
  Running setup.py egg_info for package djangorestframework

    warning: no files found matching '*.txt' under directory 'rest_framework/templates'
  Requested djangorestframework==2.2.4, but installing version 2.2.0
Installing collected packages: djangorestframework
  Running setup.py install for djangorestframework

    warning: no files found matching '*.txt' under directory 'rest_framework/templates'
Successfully installed djangorestframework
Cleaning up...
@qwcode
Python Packaging Authority member
qwcode commented Apr 20, 2013

closing due to merge of #865

@qwcode qwcode closed this Apr 20, 2013
@leorochael leorochael referenced this issue in Pylons/zodburi Apr 25, 2013
Closed

Unpack error while using RelStorage #4

@davidrenne

Added my comment to the windows local temp directory you need to delete to work around this. Once I deleted this directory everything worked fine. I am on pip 1.3.1

http://siddhi.blogspot.com/2011/09/pip-re-installing-wrong-version-of.html

It still doesnt work in windows 7.

@qwcode
Python Packaging Authority member
qwcode commented May 22, 2013

this will only be fixed in 1.4, which is not released yet.

@davidrenne
@kevin1024

THANK GOD

@kiall kiall pushed a commit to moniker-dns/devstack that referenced this issue Nov 20, 2013
@ianw ianw Use unique build dir for pip installs
There is a bug in pip [1] where it will choose to install a package
from an existing build-dir if it exists over the version actually
requested.

Thus if a prior component has installed a later version of the
package, the unpacked code is already in /tmp/$USER-pip-build; it gets
re-installed and manifests in a confusing error along the lines of

---
 Downloading/unpacking requests>=1.1,<1.2.3
   (from -r /home/stack//python-cinderclient/requirements.txt (line 5))
   Running setup.py egg_info for package requests
   Requested requests>=1.1,<1.2.3 (from -r
   /home/stack/python-cinderclient/requirements.txt (line 5)),
    but installing version 1.2.3
...
  error: Installed distribution requests 1.2.3 conflicts with
    requirement requests>=1.1,<1.2.3
---

I believe pip 1.4 fixes this problem, but it should always be safe to
specify a unique build-directory for pip installs to avoid picking up
old versions.

We also add a cleanup_tmp function for clearing out anything that
stack.sh might leave around when un-stacking, and add a catch-all for
the pip-build dir.

[1] pypa/pip#709

Change-Id: I7ce919cddfd6d6175ae67bd864f82e256ebc7090
31dcd3e
@openstack-gerrit openstack-gerrit pushed a commit to openstack-dev/devstack that referenced this issue Oct 4, 2014
@jogo jogo Drop workaround for pip < 1.4
Now that we are on pip 1.5.6 lets drop the workaround to make pip 1.4
work. As this is a development/testing tool requiring a newer pip
shouldn't be an issue. Also stack.sh installs pip by default.

Work around introduced in pypa/pip#709

Change-Id: I0e7aad1d21f4fce4c020ce36685bb56893c66bdc
944b282
@openstack-gerrit openstack-gerrit added a commit to openstack/openstack that referenced this issue Oct 4, 2014
Jenkins Updated openstack/openstack
Project: openstack-dev/devstack  39ceb484a49234147ce6670a542e2bd20ceb369f

Drop workaround for pip < 1.4

Now that we are on pip 1.5.6 lets drop the workaround to make pip 1.4
work. As this is a development/testing tool requiring a newer pip
shouldn't be an issue. Also stack.sh installs pip by default.

Work around introduced in pypa/pip#709

Change-Id: I0e7aad1d21f4fce4c020ce36685bb56893c66bdc
bf14fa3
@openstack-gerrit openstack-gerrit added a commit to openstack/openstack that referenced this issue Oct 4, 2014
Jenkins Updated openstack/openstack
Project: openstack-dev/devstack  39ceb484a49234147ce6670a542e2bd20ceb369f

Drop workaround for pip < 1.4

Now that we are on pip 1.5.6 lets drop the workaround to make pip 1.4
work. As this is a development/testing tool requiring a newer pip
shouldn't be an issue. Also stack.sh installs pip by default.

Work around introduced in pypa/pip#709

Change-Id: I0e7aad1d21f4fce4c020ce36685bb56893c66bdc
4722641
@AtnNn AtnNn referenced this issue in rethinkdb/rethinkdb Nov 6, 2014
Closed

Alex Casanova: Crash updating from 1.13 to 1.15.x #3222

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.