Closed JohannesBuchner closed 8 years ago
I used pip3.4 from Gentoo repos.
I used pip to install a local egg directory, which loaded some dependencies off the web (sqlalchemy to be precise)
I did not trim the traceback.
@JohannesBuchner: It looks like the pip dependencies have been debundled. It would be interesting to know what version of the dependencies you have compared to what pip 7.1.2 expects: https://github.com/pypa/pip/blob/7.1.2/pip/_vendor/vendor.txt
I think Gentoo does not debundle
the following is from the ebuild file
VENDOR_DEPEND="
=dev-python/distlib-0.2.1[${PYTHON_USEDEP}] =dev-python/html5lib-0.999999[${PYTHON_USEDEP}] =dev-python/six-1.9[${PYTHON_USEDEP}] =dev-python/colorama-0.3.3[${PYTHON_USEDEP}] =dev-python/requests-2.7.0[${PYTHON_USEDEP}] =dev-python/CacheControl-0.11.5[${PYTHON_USEDEP}] =dev-python/lockfile-0.10.2[${PYTHON_USEDEP}] =dev-python/progress-1.2[${PYTHON_USEDEP}] =dev-python/packaging-15.3[${PYTHON_USEDEP}] =dev-python/retrying-1.3.3[${PYTHON_USEDEP}] virtual/python-ipaddress[${PYTHON_USEDEP}] " RDEPEND="${VENDOR_DEPEND} =dev-python/setuptools-18.2[${PYTHON_USEDEP}] "
@xavfernandez ah I had missed that. I was more focused on whether urllib3 had been debundled from requests, not whether pip's dependencies had been debundled from pip.
@JohannesBuchner can you tell us what version of requests was installed? And they definitely have been debundled. I can tell by the traceback.
I'm looking at pip and https://github.com/pypa/pip/blob/c20ed50a82d7f8af793c9754f3c936794aa0b56d/pip/download.py#L323 seems to be the only place it creates a Retry
object. I have to wonder if the isinstance
check in urllib3 will not work when requests
is debundled.
I have requests 2.8.1
So yeah, I'm willing to bet that because of the vendored function in pip._vendor
we have a problem where isinstance
checks fail. I wonder if this would be fixed by appending to that list
vendored('requests.packages')
vendored('requests.packages.urllib3')
# urllib3's subpackages
@JohannesBuchner to confirm my suspicion can you run the following code?
from pip._vendor.requests.packages import urllib3
from requests.packages import urllib3 as _urllib3
r = urllib3.Retry(total=10)
if isinstance(r, _urllib3.Retry):
print('@sigmavirus24 is wrong')
else:
print('@sigmavirus24 is right')
If that ends up being correct, I'm going to write a quick patch and see if applying it helps you @JohannesBuchner because this will be a problem for other distros too (to some extent) probably.
(FWIW, my guess about needing to specify requests.packages.*.*.*
is only because I see six
, six.moves
, and six.moves.urllib
there so I'm extrapolating just a tiny bit.)
The code output says you are right.
I doubt I will be able to reproduce the conditions of the network failure.
Ah, that's true. @Lukasa thoughts on how to potentially reproduce the network failure?
Easiest way is to patch the socket module to force it to throw that particular error from getaddrinfo.
Actually, @JohannesBuchner if you can apply the patch in https://github.com/pypa/pip/pull/3287 to your installation and then run
from pip._vendor.requests.packages import urllib3
from requests.packages import urllib3 as _urllib3
r = urllib3.Retry(total=10)
if isinstance(r, _urllib3.Retry):
print('The patch fixed this')
else:
print('The patch didn't fix this')
That should be confirmation enough for me since I'm not sure we can repro this with pip's current testsuite.
I got this traceback after a network failure with urllib3 v1.10 on Linux:
Somehow pip has a Retry object which is incompatible. I reported this first with urllib3 in https://github.com/shazow/urllib3/issues/742 who say it is a bug in pip (or requests).