-
Notifications
You must be signed in to change notification settings - Fork 3k
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 1.4 doesn't upgrade setuptools properly #1117
Comments
After installing setuptools with easy_install setuptools -U everything seems to be working, so this looks like pip isn't actually installing setuptools. |
the upgrade has been validated to work many times (with older pip's and pip-1.4), so there must be something different in this case. do you mind:
this error looks familiar in that I've seen that it when running "egg_info" in the distribute-0.7.3 build dir, which won't work. |
Apologies to necromance this bug, but python-setuptools-0.9.8 shipped with CentOS 7.2 does not properly upgrade to setuptools-20-y.z. when pip is used. The workaround used in this document (using easyinstall) gets the job done, but seems wrong. After I installed setuptools-20.y.z, I removed all of the python noarch packages, and then pip properly install setuptools-20.y.z. I think the issue is related to some type of pip database on teh system, but I'm not really sure not being a python expert. |
Our upstream solution to this problem |
@sdake you could also use the get-pip.py script to bootstrap installation of the latest tools. You could even only install the latest pip:
|
I've also seen this as a part of using Docker with overlayfs, actually completely unrelated to pip. overlayfs somehow can't deal with a command doing both an uninstall & install operation (as an upgrade implies), although I am fuzzy on the details. |
@Ivoz We do that. Our full bootstrap is here: The issue is in a parent container (base), jinja2 is installed which has a hard python dependency on setuptools: Why not just use get-pip here and install these packages from source? I guess we could but we ultimately decided to hold off on doing that and install source packages in a virtualenv in our base package as is done in our openstack-base. That work was never done and I guess we should do it now. The virtualenv is here: The reflection on this bug from my standpoint is you can't mix distro packaging with pip that involves setuptools or everything goes south. Regards |
I tried upgrading to setuptools as per #1064
pip install --use-mirrors setuptools --upgrade
pip install --use-mirrors --upgrade virtualenv==1.10
This happens on a fresh install of CentOS 6.4 x86_64 (Python 2.7.3)
Also any subsequent attempts to install other packages fail just like installing virtualenv.
The text was updated successfully, but these errors were encountered: