Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
vendoring logic subtly breaks later usage of unvendored system versions after importing pkg_resources.extern #1383
In theory, if pkg_resources.extern is devendored, it should defer to the system installation of e.g. packaging, which means that:
It would be expected that I could then compare the results, since they're the same thing.
For comparison, this works fine when using the similarly devendored pip.
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.
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.
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.
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).
All I did was install a fresh Ubuntu server and attempt to list outdated packages:
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.