incorrect behavior of pip install --upgrade pip #3433
Comments
|
You likely have an other pip install that shadows the one being installed. pip reports the installed version it sees after the installation. |
|
Hmm, I don't quite get how that can be the case. If the I'm still not sure if it installed 8.0.2 and only the reporting is incorrect, or it actually installed a different wheel than it downloaded. The latter would be worse, but either way it's a bug I'd think. |
|
Would the issue diseappear if you use "--no-cache-dir" option of pip ? (suspecting the cache management of pip, or between versions of pip) |
|
The issue seems to be that when you have two or more This I concluded from another attempt on a different machine:
|
|
would it be possible that pip is looking in all your path for packages , giving back a merge of the two places ? |
|
Don't think that's it. It goes wrong somewhere in the ping pong between |
|
Well, maybe the phrasing should be improved, pip should report the installed version and not the one on the path ? |
|
@xavfernandez I don't think that helps - I'm still ending up with an older
What happens at the moment is:
|
|
I haven't found a good way to debug this by the way. I can reproduce the issue, but it's hard to figure out what is being done. And since |
|
how fun: today the same issue on windows (just setuptools instead of pip): pip list indicates setuptools-19.4 after that. trying the exact same command again (on same dos session), I get a: there is zero system "Python" on my pc, the path is clean from other Pythons (which are legions) ==> does it give a clue to the problem ? and I don't reach the Line 343 in b681665 I did that just after doing the same upgrade on a python 2.7, with no apparent failure, in another dos process, but in same user session. |
|
To get the data to properly diagnose this, we really need the following:
Really, we need the above from before reproducing the issue - maybe after as well, for completeness, but before is the key one. Because after you reproduce the issue, you've possibly changed what pip versions are installed (although not in the way you wanted to, unfortunately :-(). |
|
just a possibility of idea, I moved these directories, and I can see a reference to the original place in the, for example, D:\result_tests\winpython-3.4.3.6\python-3.4.3\Lib\site-packages\setuptools-18.4.dist-info "RECORD" file: there are two non-relative path in there: |
|
I think the initial break is that pip from did find and removed easy_install.exe at where the original build was made (and a new one after) |
Ha, that's the issue. Moving/renaming the Python directory isn't something I'd recommend (and definitely isn't something you should do without understanding the implications). As you can see, there are absolute pathnames in there, so that's likely your issue. I'd say that we try to do our best to make pathnames relative, but it's not something we guarantee - and it's not always pip that writes the RECORD data, so it's just as likely to be something like setuptools. You can probably manually fix things up if you do move the directory, but it's definitely an area where "if you break it, you get to keep both pieces" applies :-) |
|
so it's a setuptools corner-case bug ? does it explain rgommers issue ? |
|
It's a result of you doing something unsupported (moving a Python installation). It's unlikely to be the same as @rgommers issue unless he moved his Python installation. You might be able to get some support for the idea that tools should ensure that all paths in |
|
and which tools do write that RECORD (and delete based on it) ? so I can ask for a feature improvement in my corner case ? (it's not a bug, it's a lack of feature) |
No, I definitely didn't do that on any of my systems. |
I'm not sure. At least setuptools, and I think distutils. And pip and wheel for wheel-based installs. In this case (an exe wrapper) you can exclude distutils, as it doesn't write exe wrappers. Which is the likely culprit depends on how you installed setuptools. And BTW, I stand corrected on whether it's a bug - https://www.python.org/dev/peps/pep-0376/#record seems to state that this should be a relative path (the second case for a path applies, I think). But PEP 376 hasn't been followed particularly closely, historically, so don't assume that a PEP 376 incompatibility will be seen as a major problem in itself. |
|
@rgommers since you apparently found a way to reproduce the issue, could you run |
|
@pfmoore I try to do only wheel installations, so do I understand well that pip is the program who writes (and later replay for removal) these absolute-path records in RECORD ? |
|
Sounds possible. |
|
so maybe this is the right place to ask for this tiny improvement ? |
|
The usual reply applies - contributions gratefully accepted :-) (Personally, hunting down where this occurs isn't going to be a high priority for me) But yes, the issue is noted. |
|
I failed to guess yesterday on which part of pip, when installing a wheel, the RECORD is written (especially for the entry-point records which are my concern). could you pinpoint me to the correct part of program of the project ? (same for uninstall or upgrade would be nice also) |
|
I'd guess |
|
interesting, if I look at https://github.com/pypa/pip/blob/develop/pip/wheel.py#L274..L283 the following example: gives me a correct relative result. |
|
looking further, I found the last one of the group of absolute lines: https://github.com/pypa/pip/blob/develop/pip/wheel.py#L506 |
|
ok, the absolute things are only at https://github.com/pypa/pip/blob/develop/pip/wheel.py#L520..L522 |
RECORD now contains only relative path. some bugs triggered by a bleeding edge usage of python may disappear a result (pypa#3433)
ghost
mentioned this issue
|
I'm very happy that I resolved this issue. Beacuse Devstack always install the relations with the certain version from config file. if you change pip<8 to pip<9, this issue will be resolved. But there will be more problems about version. Actually, the main point is that, you write the wrong format in local.conf. Maybe your devstack version is kilo or liberty, but you fill your local.conf from openstack website, the config form website is for the latest version of devstack, that is different from other versions. for example. the config about ceilometer liberty: In a word, you should fill right config in local.conf for your devstack version, all the version problems will go away. |
|
Closing this issue which seems to contain several issues. |
|
the original issue indeed seems to be resolved now. |
lock
bot
added
the
auto-locked
It installs a different version (7.1.2) than it downloaded (8.0.2). No idea how that's even possible, even if I had a 7.1.2 wheel already cached from an install for a different Python version.
The text was updated successfully, but these errors were encountered: