vendoring logic subtly breaks later usage of unvendored system versions after importing pkg_resources.extern

[eli-schwartz]

In theory, if pkg_resources.extern is devendored, it should defer to the system installation of e.g. packaging, which means that:

>>> packaging.version
<module 'pip._vendor.packaging.version' from '/usr/lib/python3.6/site-packages/packaging/version.py'>
>>> pkg_resources.extern.packaging.version
<module 'pip._vendor.packaging.version' from '/usr/lib/python3.6/site-packages/packaging/version.py'>

It would be expected that I could then compare the results, since they're the same thing.

>>> pkg_resources.extern.packaging.version.parse('3.0') == packaging.version.parse('2.0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '>' not supported between instances of 'Version' and 'Version'

Oops?

For comparison, this works fine when using the similarly devendored pip.

>>> pip._vendor.packaging.version
<module 'packaging.version' from '/usr/lib/python3.6/site-packages/packaging/version.py'>
>>> packaging.version
<module 'packaging.version' from '/usr/lib/python3.6/site-packages/packaging/version.py'>
>>> pip._vendor.packaging.version.parse('3.0') > packaging.version.parse('2.0')
True

Note that pkg_resources must not be devendored from pip, or else it must be deleted from vendor/__init__.py, since otherwise it will be automatically imported. Even importing pkg_resources causes pip to fail as well.

>>> import pip._vendor.packaging.version
>>> import packaging.version
>>> pip._vendor.packaging.version.parse('3.0') > packaging.version.parse('2.0')
True

vs.

>>> import pip._vendor.packaging.version
>>> import pkg_resources.extern
>>> import packaging.version
>>> pip._vendor.packaging.version.parse('3.0') > packaging.version.parse('2.0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '>' not supported between instances of 'Version' and 'Version'

pypa/pip#5429 (comment) suggested the problem is deleting the global module unconditionally, whenever something vendored is in use. This strikes me as incredibly dangerous.

[yan12125]

I believe issue #580 is related. Seems setuptools maintainers were considering switching to the pip approach regarding vendoring to fix such issues.

[jaraco]

The origin of that hack is 6a5145a. Even though I wrote that code and I've stared at it for at least 15 minutes, I don't fully understand what's going on there. It seems plausible that the hack is over-reaching and really should only be employed when there's a prefix. So let's give that patch a go.

[jaraco]

In the commit, @richard-scott reports that the patch (subtly altered) didn't fix the issue.

What we could use at this point is a way to replicate the issue. Could someone devise a recipe that replicates the issue (preferably in a virtualenv and cross-platform or in a docker image).

[richard-scott]

All I did was install a fresh Ubuntu server and attempt to list outdated packages:

$ pip3 list --no-cache-dir --disable-pip-version-check --outdated --format=freeze

That said, I've removed the fix and the above command now works. My setup does automatically patch any pip packages on boot, so one of those may have been updated.

I'm currently running pip-10.0.1, and setuptools-40.0.0.

[yan12125]

I'm currently running pip-10.0.1, and setuptools-40.0.0.

@richard-scott This might be the reason for the breakage. You need setuptools >= 40.0.0 and pip >= 19.1 to get this command working with unvendored pip.