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

Old version of package in build/ prevents upgrade #709

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

Old version of package in build/ prevents upgrade #709

scjody opened this issue Oct 22, 2012 · 13 comments
Labels
auto-locked Outdated issues that have been locked by automation type: bug A confirmed bug or unintended behavior

Comments

@scjody
Copy link

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
Copy link
Author

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
Copy link
Contributor

pnasrat commented Oct 23, 2012

What version of pip did you test this with?

@scjody
Copy link
Author

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
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

qwcode commented Apr 20, 2013

closing due to merge of #865

@davidrenne
Copy link

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
Copy link
Contributor

qwcode commented May 22, 2013

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

@davidrenne
Copy link

Nice great work guys!

Sent from my iPhone

On May 22, 2013, at 7:12 PM, Marcus Smith notifications@github.com wrote:

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


Reply to this email directly or view it on GitHub.

@kevin1024
Copy link

THANK GOD

kiall pushed a commit to moniker-dns/devstack that referenced this issue Nov 20, 2013
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
openstack-gerrit pushed a commit to openstack/devstack that referenced this issue Oct 4, 2014
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
openstack-gerrit pushed a commit to openstack/openstack that referenced this issue Oct 4, 2014
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
openstack-gerrit pushed a commit to openstack/openstack that referenced this issue Oct 4, 2014
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
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 6, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 6, 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 type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

No branches or pull requests

9 participants