FS#58670 - [python-pip][python-setuptools] list --outdated: TypeError: '>' with 10.0.1-1
Attached to Project:
Arch Linux
Opened by David McInnis (daavve) - Sunday, 20 May 2018, 04:22 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 05 June 2018, 21:05 GMT
Opened by David McInnis (daavve) - Sunday, 20 May 2018, 04:22 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 05 June 2018, 21:05 GMT
|
Details
$ pip list -o
Exception: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/pip/_internal/basecommand.py", line 228, in main status = self.run(options, args) File "/usr/lib/python3.6/site-packages/pip/_internal/commands/list.py", line 145, in run packages = self.get_outdated(packages, options) File "/usr/lib/python3.6/site-packages/pip/_internal/commands/list.py", line 156, in get_outdated dist for dist in self.iter_packages_latest_infos(packages, options) File "/usr/lib/python3.6/site-packages/pip/_internal/commands/list.py", line 157, in <listcomp> if dist.latest_version > dist.parsed_version TypeError: '>' not supported between instances of 'Version' and 'Version' Reported upstream: https://github.com/pypa/pip/issues/5429 |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Tuesday, 05 June 2018, 21:05 GMT
Reason for closing: Fixed
Additional comments about closing: python-setuptools 1:39.2.0-2
Tuesday, 05 June 2018, 21:05 GMT
Reason for closing: Fixed
Additional comments about closing: python-setuptools 1:39.2.0-2
pip._vendor.packaging.version.Version and pkg_resources.extern.packaging.version.Version are actually the same class (both are packaging.version.Version), while Python does not think so.
Is it so hard to believe that an issue can be because of the intersection of upstream and downstream, with neither being fully to blame?
...
https://github.com/pypa/pip/issues/5429#issuecomment-390866478
This happens because pip is using incompatible import paths in *their* code, which is obscured when not using the devendoring code *they* provide due to the fact that *their* import rewrites map both versions to the same filesystem location, whereas devendoring does not.
We could, of course, solve this by maintaining downstream patchsets to update all import paths to use their system versions, which is kind of basically what pip does (but in reverse) by maintaining patches which rewrite the import paths to use the top-level pip._vendor path. But this is obviously sort of a pain, so we're trying to use their devendoring code.
... which, due to PyPA's heavy encouragement of using the "it just works" vendored version, does not get much testing, which is something we'd like to change as it solves irritating bugs like
FS#40713.Please fix your bugtracker link in the second comment of the linked pip issue, as it currently sends people to vote on this bug if they're logged in, whether they intended to or not.
Thanks for whoever re-opened the bug.
My bad,,
-Dave
Since pip is moved to extra, this currently means this bug will see much more exposure... upstream does not seem to be responding on this bug and I don't know exactly how broken their devendoring logic is, so I think it is best to just rewrite the import paths for now.
Pushed updated setuptools into [extra].