FS#62592 - [python-requests] spews warning with urllib3 > 1.24

Attached to Project: Arch Linux
Opened by David McInnis (daavve) - Friday, 10 May 2019, 14:15 GMT
Last edited by Felix Yan (felixonmars) - Thursday, 16 May 2019, 19:01 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 16
Private No

Details

Description: python-requests raises exception if urllib3 not between versions 1.21.1 & 1.24. If python-urllib3-1.25 is installed python-requests will always fail with an exception when it checks urllib3 version.
* package version(s)

testing/python-urllib3-1.25.2-1
extra/python-requests 2.21.0-1


* link to upstream bug report, if any

https://github.com/kennethreitz/requests/issues/5065

Steps to reproduce:

1) Install package versions

Try to use "pip search"

$pip search acpilight
/usr/lib/python3.7/site-packages/requests/__init__.py:91: RequestsDependencyWarning: urllib3 (1.25.2) or chardet (3.0.4) doesn't match a supported version!
RequestsDependencyWarning)


I made a work-around fix by manually changing __init__.py in the pkbuild to the following:

$ diff src/requests-2.21.0/requests/__init__.py ../src/requests-2.21.0/requests/__init__.py
60c60
< # urllib3 >= 1.21.1, <= 1.24
---
> # urllib3 >= 1.21.1, <= 1.25
63c63
< assert minor <= 24
---
> assert minor <= 25


# Now at least "pip search" works for me. Wasn't able to get the PKGBUILD check() to run properly though.

-Dave
This task depends upon

Closed by  Felix Yan (felixonmars)
Thursday, 16 May 2019, 19:01 GMT
Reason for closing:  Fixed
Additional comments about closing:  2.22.0-1
Comment by Doug Newgard (Scimmia) - Friday, 10 May 2019, 14:26 GMT
So now it throwing a warning means it fails? Really?
Comment by David McInnis (daavve) - Friday, 10 May 2019, 14:40 GMT
I made a mistake, the above patch isn't necessary for pip to work, it only suppresses the error message.

The above patch might come in handy as a workaround for any package that breaks due to the handling of the warning exception.
Comment by David McInnis (daavve) - Friday, 10 May 2019, 14:42 GMT
Comment by Andrzej Giniewicz (Giniu) - Saturday, 11 May 2019, 19:37 GMT
urllib guys say it is not supported https://github.com/urllib3/urllib3/issues/1571#issuecomment-487928521 so some things might not work
Comment by Jérémy Lecocq (Vrakfall) - Saturday, 11 May 2019, 20:28 GMT
A very simple script that shows the response of a request on my UI recently started to show this warning as well. Tho, I was able to remove it with the `-W ignore` flag and the output came back to normal (read: it didn't make my script fail).
On the other hand, it's still an issue, even if just a warning (and I'm not sure it is just that, or not).
Comment by loqs (loqs) - Saturday, 11 May 2019, 20:45 GMT
What happens if you apply https://github.com/kennethreitz/requests/commit/d6b5b401e8d6141bcefa4a70ff1c836aa085120b ?
Comment by Jérémy Lecocq (Vrakfall) - Saturday, 11 May 2019, 23:09 GMT
On a side note, I believe this also breaks the `streamlink-twitch-gui` AUR package. I can't be certain as the log only outputs `Error: Unexpected version check output` when you try to load a stream and nothing else (and the stream won't load, ofc). Internally, it uses `streamlink` (community) which depends on `python-requests`. This last one still works but outputs the same error message as described in the ticket. I believe `streamlink-twitch-gui` parses that line, interprets it as an error and stops the `streamlink` process even though it would still play the stream. (I suppose they also use that text output to list all the different sub-streams available, like different qualities (720p30, 1080p60,...).)

I'm aware this isn't a direct breakage and is a potential flaw in `streamlink-twitch-gui`'s way to handle `streamlink`, because this possibility isn't considered, and I'm going to submit a ticket and their repo.
Comment by Jérémy Lecocq (Vrakfall) - Saturday, 11 May 2019, 23:19 GMT
Nevermind, they already have multiple bug report on this matter, I just didn't look hard enough in there. So it is confirmed, it does affect that AUR package.
https://github.com/streamlink/streamlink/issues/2448
https://github.com/streamlink/streamlink/issues/2446
Comment by David McInnis (daavve) - Sunday, 12 May 2019, 22:29 GMT
Hi. Misunderstood the problem when I posted the initial bug. If you are using "pip search" you get a warning, then the pip search works as normal.

Different applications handle exceptions differently when using the python-requests package. Therefore, individual dependent packages may or may not be effected.

-Dave
Comment by Eli Schwartz (eschwartz) - Sunday, 12 May 2019, 23:14 GMT
  • Field changed: Summary ([python-urllib3-1.25] Python-requests fails with exception with urllib3 > 1.24 → [python-requests] spews warning with urllib3 > 1.24)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Category (Packages: Testing → Packages: Extra)
  • Task assigned to Felix Yan (felixonmars)
Warnings are not errors. That being said, this is still an exceedingly annoying warning, and it is caused by the fact that requests does restrictive dependency version pinning, both install-time and runtime.

Attached patch almost gets requests to build, including passing the testsuite with pytest 4, except for one failing test in which requests failed to raise a SubjectAltNameWarning when it thought it should. This is a general issue with trying to rebuild requests regardless of urllib3 version.
   requests-urllib.diff (3 KiB)
Comment by Jérémy Lecocq (Vrakfall) - Monday, 13 May 2019, 09:11 GMT
Yup, I just wasn't sure (at the time) if it was a warning or a real Exception containing the string "Warning" within it (mainly because the output was weird, on a new line and also because I misinterpreted the first message and thought it was breaking all children). It's only later during my exploration I figured out it's just a warning.

Thank you Eli, I'm glad to see a fix is almost done!
Comment by Felix Yan (felixonmars) - Thursday, 16 May 2019, 19:01 GMT
@Eli Thanks for the patch!

Should have been fixed in 2.22.0-1. Sorry for the delay.

Loading...