Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Dan McGee (toofishes)
Felix Yan (felixonmars)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

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
2019-10-27: A request to re-open the task has been made. Reason for request: It happens again: ~> /usr/bin/pip -V pip 19.2.3 from /usr/lib/python3.7/site-packages/pip (python 3.7) ~> pip list -o ERROR: Exception: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/pip/_internal/cli/base_command.py", line 188, in main status = self.run(options, args) File "/usr/lib/python3.7/site-packages/pip/_internal/commands/list.py", line 156, in run packages = self.get_outdated(packages, options) File "/usr/lib/python3.7/site-packages/pip/_internal/commands/list.py", line 164, in get_outdated dist for dist in self.iter_packages_latest_infos(packages, options) File "/usr/lib/python3.7/site-packages/pip/_internal/commands/list.py", line 165, in <listcomp> if dist.latest_version > dist.parsed_version TypeError: '>' not supported between instances of 'Version' and 'Version'
Comment by David McInnis (daavve) - Monday, 21 May 2018, 14:54 GMT
Upstream seems to think this is an Arch Linux packaging issue:


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.
Comment by Genevieve Mendoza (aenda) - Monday, 21 May 2018, 16:31 GMT Comment by Eli Schwartz (eschwartz) - Tuesday, 22 May 2018, 05:31 GMT
I find it somehow irritating when people close upstream issues as soon as it looks like the distribution might be remotely related to the cause. :(

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 .
Comment by Eli Schwartz (eschwartz) - Tuesday, 22 May 2018, 07:10 GMT
@daavve,

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.
Comment by Eli Schwartz (eschwartz) - Sunday, 27 May 2018, 04:51 GMT Comment by David McInnis (daavve) - Thursday, 31 May 2018, 07:24 GMT
Sorry I closed the upstream issue so quickly. I am not an expert on python packaging(even through I maintain a bunch of python packages). I assumed, possibly incorrectly that the person suggesting that this a downstream bug was expert enough in the pip package to know for-sure the downstream package was to blame.

Thanks for whoever re-opened the bug.

My bad,,

-Dave
Comment by David McInnis (daavve) - Thursday, 31 May 2018, 07:30 GMT
@eschwartz Sorry about the miscommunication. I fixed the second comment in the GitHub issue as requested.
Comment by Eli Schwartz (eschwartz) - Sunday, 03 June 2018, 06:13 GMT
felix, please update setuptools to use a more thorough devendoring approach, see the attached PKGBUILD.

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.
   PKGBUILD (3.9 KiB)
Comment by Felix Yan (felixonmars) - Sunday, 03 June 2018, 15:32 GMT
I meant to keep the problematic pip in [testing] for longer but it seems someone else moved it :(

Pushed updated setuptools into [extra].

Loading...