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.

[jaraco]

Signal boost for #2052, closed as a duplicate of this issue, which contains a lot of context and discussion.

[jaraco]

The sole replication I have for this issue is that from @richard-scott, which appears no longer to be an issue:

draft $ cat Dockerfile
FROM ubuntu:focal
RUN apt update
RUN apt upgrade -y
RUN apt install -y python3-pip
draft $ docker run -it @$(docker build -q .) pip3 list --no-cache-dir --disable-pip-version-check --outdated --format=freeze
pip==20.0.2
setuptools==45.2.0
wheel==0.34.2

The examples from the original post don't include prerequisite steps, so it's difficult to tell what packaging or pkg_resources are.

Is this issue still present? If so, what use-cases are still degraded?

[mgorny]

This still happens when unvendoring is done, i.e. after removing pkg_resources/_vendor.

My reproducer is:

import packaging.version

v1 = packaging.version.parse('1.2.3')

import pkg_resources.extern.packaging.version

v2 = packaging.version.parse('2.3.4')

v1 < v2

Unfortunately, something similar happens in polybar's sphinx logic. IIUC one Version is created early, another one much later and I suspect in between Sphinx imports pkg_resources somewhere.

[mgorny]

Ironically, this bug is now causing 60.6.0 tests to fail:

_______________________________________________________ TestDepends.testRequire _______________________________________________________
[gw10] linux -- Python 3.9.10 /tmp/portage/dev-python/setuptools-60.6.0/work/setuptools-60.6.0-pypy3/install/usr/bin/pypy3

self = <setuptools.tests.test_setuptools.TestDepends object at 0x000055ee2b945d70>

    @needs_bytecode
    def testRequire(self):
        req = Require('Json', '1.0.3', 'json')
    
        assert req.name == 'Json'
        assert req.module == 'json'
>       assert req.requested_version == version.Version('1.0.3')
E       AssertionError: assert <Version('1.0.3')> == <Version('1.0.3')>
E         +<Version('1.0.3')>
E         -<Version('1.0.3')>

req        = <setuptools.depends.Require object at 0x000055ee2ea540c8>
self       = <setuptools.tests.test_setuptools.TestDepends object at 0x000055ee2b945d70>

/tmp/portage/dev-python/setuptools-60.6.0/work/setuptools-60.6.0/setuptools/tests/test_setuptools.py:94: AssertionError

[mgorny]

If anyone else's still looking for a "good enough" hack, I've ended up taking unbundling one step further and removing setuptools.extern and pkg_resources.extern entirely:

	rm -r */extern || die
	find -name '*.py' -exec sed \
		-e 's:from \w*[.]extern ::' -e 's:\w*[.]extern[.]::' \
		-i {} + || die