-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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 --upgrade pip installs 10.0.0b2 (beta?) on ubuntu 12.04 #5156
Comments
Wow, pip 1.0 is a very old version! As far as I know, recent versions of pip should not install the beta unless you pass an explicit Yeah, I did some digging into the git history, and the |
Yes we agree this is an old version, but it's still python 2.7 and the new pip 10.0.0b2 can't install setuptools... So is it not retro-compatible or just a problem of this version? Should we open an issue specifically for 10.0.0b2 not installing setuptools on python 2.7? |
That |
I suspect the problem is that CPython changed something between the version of 2.7 in Ubuntu 12.04 and the latest version of 2.7 that the msgpack library isn't setup to handle and it causes an error there. |
We tested on trusty with a 2.7.6 python and it worked with pip 10.0.0b2... that means you are probably right our python 2.7.3 is probably the cause, and it is the version packaged version for 12.04 (precise pangolin). So i think having 3 too old version (pip, python and ubuntu) is a bit too much. Let's call this a day and pip install to a <=9.0.3 before doing an open pip upgrade will be the solution. Thanks all! |
Kind of sad to see this get closed as a "that was weird" resolution... Running in a Debian 9 Container (openjdk:jdk-8) fully updated installing Napalm was succeeding last week and this week is not... After a day of digging the throw down rat is running After removing the offending upgraded pip and using the packaged pip (9.0.1) on openjdk:jdk-8 everything is magically working. I won't disagree that 2.7 is ancient, but unfortunately the breaking changes in python3 and the lack of community (and closed source vendors) motivation to update and their code to be compatible with python3 really leaves most of us in a really crappy situation, those who have updated their code fling mud at those who have not, leaving the users stuck in the middle of "it sucks, I suck for needing resonable backwards compatibility, and you suck for acting that way". Surely there has to be a way to make this not suck so exceptionally. |
Upgrading pip 1.0 directly will always be a problem because that version didn't have a "don't install prereleases" flag. The fix for that is to do it in 2 phases - 1.0 to 1.4+ then 1.4+ to latest (non-prerelease). Python 2.7 needs to be upgraded to later versions to keep up with current security vulnerabilities. There's no real way round that. I assume that your OS vendor provides updates to the current version of 2.7, but if not, then I guess that's a manual job. Not sure what else we can offer here? |
In general pip works fine on 2.7, it's only sufficiently old versions of 2.7 that have the specific problem in this issue. Debian 9 is using 2.7.13 so that's pretty recent, are you getting the same error message, the one that looks like:
Or are you getting a different one? If it's a different one then that is a different issue and would need to be raised individually. |
I am receiving pip.req missing
Regardless of the error getting a beta release without flag is the cause (directly or indirectly) Here is replication steps:
This is in a openjdk:8-jdk container which is debian 9. Clearly something is suspect with the 10.0.0b2 release. And let me be VERY clear on this... we are not talking V1.X.X we are talking V10 which was just released 3 days ago at 10.0.0b1 and yesterday at 10.0.0b2 |
So that sounds entirely different? You're using easy_install to install pip, so if there is a bug here, it's in easy_install, not pip. And using easy_install to install has been deprecated for ages, as far as I know. Also, you're doing from But all of this is different issues from the OP's problem. |
pfmoore fair enough... I am happy to live on 9.x, but my argument was more to the effect of the OP's complaint being valid... a Beta release is going out via main stream distribution method, to further demonstrate that effect, seeing the beta release is now absent from https://pypi.python.org/simple/ suggests that this is known and resolved... I am happy to call it a day on this front but, easy_install still is distributing where as the means of the OP's complaint no longer is passing the beta release out. |
It's not absent, it's still there and available for install. |
Would you mind posting a link to that announcement and indicating what is the proposed alternative? |
https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html and https://pip.pypa.io/en/latest/user_guide/#using-pip-from-your-program Short answer: If you're using subprocess.call([sys.executable, '-m', 'pip', ...]) which does the same but in a supported manner. If you're using any other pip internal APIs, they have never been supported, are likely to have been broken by the internal processing changes in pip 10 anyway, and you should look for other 3rd party packages (or the relevant standards which will allow you to code your own alternatives) that offer the functionality you need. |
I see two problems:
Not saying I disagree with your decision, it's yours to take after all, just that it's going to cause havoc and break a lot of things for no real reason other than "to give people the incentive to find a supported approach". And all that without even raising a |
Sorry but this is off topic for this issue (which is about pip 1.0!). To clarify (although this has been discussed repeatedly on many other issues where people have asked "does pip have a programming API?") pip is a command line tool, and doesn't have a programming API - it never has. Expecting users to call pip as a subprocess is no more unusual than expecting users to call git that way - you wouldn't expect to be able to
|
I agree it's off topic so let's leave it be. Thanks for the info and the pointers btw. |
Just to add to this, about why we did this. Users regularly complained about how their script/tool (that reached into pip's internals for something) doesn't work now because pip made an internal change and it was a constant drain on the volunteered development resources we have. (if you search "not supported" in closed issues on this repo, you'll get a long list of closed issues where it has been stated. Open one and you'll likely to get an idea of how those discussions go.) I personally feel this move makes it easier for all parties involved in the longer term. |
What I've run:
What I've got:
|
More than that, |
pip appears to throw this TypeError while loading a cached dependency from its cache directory. |
@ajdavis Thanks, |
Using --no-cache-dir is just a work around to it , just clean ~/.cache/pip/ things should work |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Description:
Hello,
First of all we're sorry for bringing 12.04 to the table.
When installing python-pip by apt-get we get pip 1.0. So the first move is to upgrade pip and setuptools ASAP.
The problem seems to be pip 1.0 installing the version 10.0.0b2 which is a beta version we think, and this leads to setuptools failing with this:
What I've run:
This is a docker file to reproduce the problem:
We can workaround this by capping pip to 9.0.3 but we were wondering if there's a better solution...
Maybe the debian package could install a better version? (Debian might be mad bro)
Maybe pip should not install 10.0.0b2? (but i understand that you don't support pip 1.0)
Maybe 10.0.0b2 should not fail at updating setuptools?
Thank you very much for your hard work.
The text was updated successfully, but these errors were encountered: