Use urllib3.util.retry from requests.packages [RHELDST-5671] #32
Conversation
|
This repo hadn't received changes in a while and the CI was still wrongly pointing at travis-ci.org (now offline). I fixed it to point at travis-ci.com. Could you please do an empty "git commit --amend" and push, or maybe close/reopen the PR, so that travis-ci.com starts a test run? |
MichalHaluza
dismissed stale reviews from rohanpm and crungehottman
via
b7c776b
MichalHaluza
force-pushed
the
requests-urllib-retry
branch
3 times, most recently
from
f932ef6
to
4b70486
Compare
|
Hmm, so as it turns out Sufficiently new versions of requests module stopped bundling its own urllib3 again, but ship with a backwards-compatibility module which still provides I'm compelled to leave |
MichalHaluza
force-pushed
the
requests-urllib-retry
branch
from
4b70486
to
25aecd8
Compare
Fixes TypeError: unsupported operand type(s) for -=: 'Retry' and 'int' Requests module historically bundled its own urllib3, which makes the whole Session-HTTPAdapter-Retry chain behave unexpectedly. HTTPAdapter always calls Retry.from_int() regardless of the max_retries parameter type. Retry.from_int() method either creates a new instance of Retry or compares if the parameter already is a Retry instance and returns it unchanged. The problem here is that urllib3.util.retry.Retry is not the same as requests.packages.urllib3.util.retry.Retry, so the non-bundled retry object is wrapped into the bundled Retry object and is treated as integer from then on, leading to the TypeError above. Sufficiently new versions of requests module (>=2.16) stopped bundling its own urllib3, but ship with a backwards-compatibility module which still provides requests.packages.urllib3.util.retry.Retry which is once again an alias of urllib3.util.retry RHEL-6 and RHEL-7 python-requests packages ship their own version of requests.packages.urllib3.* which aliases the real top-level urllib3 module, so this code adjustment should work even on legacy systems without urllib3 bundled with requests.
MichalHaluza
force-pushed
the
requests-urllib-retry
branch
from
25aecd8
to
426e0f3
Compare
|
A CI failure remains, I understand it's not introduced by this change but instead a pylint upgrade, but it'll have to be resolved nevertheless. |
PEP-597 adds optional EncodingWarning when encoding parameter to open() is omitted. In such case, the default locale-specific encoding is used, which is acceptable in this case and also retains backwards-compatibility with python 2, so only the pylint warning needs to be suppressed.
|
All checks have finally passed. |
Fixes
TypeError: unsupported operand type(s) for -=: 'Retry' and 'int'
Sufficiently new versions of requests module bundle its own urllib3,
which makes the whole Session-HTTPAdapter-Retry chain behave
unexpectedly. HTTPAdapter always calls Retry.from_int() regardless
of the max_retries parameter type. Retry.from_int() method either
creates a new instance of Retry or compares if the parameter already
is a Retry instance and returns it unchanged. The problem here is
that urllib3.util.retry.Retry is not the same as
requests.packages.urllib3.util.retry.Retry, so the non-bundled retry
object is wrapped into the bundled Retry object and is treated
as integer from then on, leading to the TypeError above.
RHEL-6 and RHEL-7 python-requests packages ship their own version of
requests.packages.urllib3.* which aliases the real top-level urllib3
module, so this code adjustment should work even on legacy systems
without urllib3 bundled with requests.