Requests is running with a non urllib3 backend reached

Hello,

When testing Ansible & WinRM today, I hit the Requests is running with a non urllib3 backend condition at https://github.com/requests/requests-kerberos/blob/v0.12.0/requests_kerberos/kerberos_.py#L158, which I'm not sure should be possible:

/usr/lib/python2.7/site-packages/requests_kerberos/kerberos_.py:160: NoCertificateRetrievedWarning: Requests is running with a non urllib3 backend, cannot retrieve server certificate for CBT
  NoCertificateRetrievedWarning)

When adding at https://github.com/requests/requests-kerberos/blob/v0.12.0/requests_kerberos/kerberos_.py#L158

print(raw_response.__class__)
print(HTTPResponse)

I got :

<class 'requests.packages.urllib3.response.HTTPResponse'>
<class 'urllib3.response.HTTPResponse'>

That's probably related to the stuffs requests is doing in https://github.com/requests/requests/blob/v2.6.0/requests/packages/__init__.py

> python
>>> from requests.packages.urllib3 import HTTPResponse
>>> HTTPResponse
<class 'urllib3.response.HTTPResponse'>
>>> import sys; from pprint import pprint
>>> pprint(sys.modules)
[..]
 'requests.packages.urllib3.response': <module 'requests.packages.urllib3.response' from '/usr/lib/python2.7/site-packages/urllib3      /response.pyc'>,
 'urllib3.util.response': <module 'urllib3.util.response' from '/usr/lib/python2.7/site-packages/urllib3/util/response.pyc'>,

Some infos in the env:

# pip list
[..]
ansible                      2.5.5
pywinrm                      0.3.0
requests                     2.6.0
requests-kerberos            0.12.0
urllib3                      1.10.2

2.6.0 is a truly ancient version. It's several years old. It's also likely, given what you printed, that you're using distribution packages of these projects which often come with ill-considered, buggy, and improper patches by the distributors who package them.

I'll check the eventual distro patches, but yes it's clearly an old version.
A workaround could be to test class name instead of testing "belonging" (not sure this is the correct word):

if raw_response.__class__.__name__ == 'requests.packages.urllib3.response':

Note that I'm not expecting this to be implemented, just thinking here (and sharing).

Or more correctly:

if raw_response.__class__.__module__ == 'requests.packages.urllib3.response' and raw_response.__class__.__name__ == 'HTTPResponse':

So what you've told me is that even though we're doing:

requests-kerberos/requests_kerberos/kerberos_.py

Line 20 in 393e49c

from requests.packages.urllib3 import HTTPResponse

you're still seeing HTTPResponse as if someone has modified our source to do from urllib3 import HTTPResponse. Is that right?

you're still seeing HTTPResponse as if someone has modified our source to do from urllib3 import HTTPResponse. Is that right?

Yes

I've checked the distro requests package, urllib3 and chardet are not bundled:

> ls /usr/lib/python2.7/site-packages/requests/packages/
__init__.py  __init__.pyc  __init__.pyo

It seems https://github.com/requests/requests/blob/v2.6.0/requests/packages/__init__.py#L87 is acting, hence

> python
>>> from requests.packages.urllib3 import HTTPResponse
>>> HTTPResponse
<class 'urllib3.response.HTTPResponse'>

Like you said, this is an old version, but it is the one used in CentOS 7 (https://git.centos.org/tree/rpms!python-requests.git/c7 / https://centos.pkgs.org/7/centos-x86_64/python-requests-2.6.0-1.el7_1.noarch.rpm.html).

#128 (comment) seems to be working correctly.
No idea why there's 2 different module path returned though, maybe because of the way it's called (from inside or outside of requests).

So what I'm hearing is that you're stuck on a version of Requests that is patently broken and unsupported by upstream Requests because CentOS 7 only packages that version. In that case, this isn't a bug of requests-kerberos, which is doing the right thing for a Requests-related package (importing from requests.packages.) but instead a problem with your distribution's packages. I would suggest that you instead file a bug with your distribution as this is a problem with the version they package.

There were several bugs reported upstream (years ago) for the code in requests/packages/__init__.py that were fixed before that magic machinery was removed as far too buggy and overly complex. I'm sure the CentOS folks would be happy to arbitrarily patch things to make them work less poorly for you.

Closing as per the above, this is also a warning rather than an outright failure which can be silenced if needed.