urllib3 v1.25 support

[EpicWink]

Support for urllib3 v1.25 (released today/yesterday). The usual yada-yada "my CI is broken".

Multiple packages that we depend on (eg google.cloud.storage, azure.storage) have strict version-check on requests using pkg_resources.require('requests >= 2.18.0'). Any unmet dependencies in the chain below and including requests will cause the check to fail and raise an exception. urllib3<1.25 is currently one such dependency.

Expected Result

No exception raised on import

Actual Result

pkg_resources.ContextualVersionConflict: (urllib3 1.25 (/usr/local/lib/python3.6/dist-packages), Requirement.parse('urllib3<1.25,>=1.21.1'), {'requests'})

The above exception was the direct cause of the following exception:
ImportError: ``requests >= 2.18.0`` is required by the ``google.resumable_media.requests`` subpackage.
It can be installed via
    pip install google-resumable-media[requests].

Reproduction Steps

pip3 install sentry-sdk google-cloud-storage

>>> from google.cloud import storage

System Information

/home/laurie/env-tmp/lib/python3.6/site-packages/requests/__init__.py:91: RequestsDependencyWarning: urllib3 (1.25) or chardet (3.0.4) doesn't match a supported version!
  RequestsDependencyWarning)
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.8"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.7"
  },
  "platform": {
    "release": "4.18.0-17-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.21.0"
  },
  "system_ssl": {
    "version": "1010100f"
  },
  "urllib3": {
    "version": "1.25"
  },
  "using_pyopenssl": false
}

[EpicWink]

Note that a pull-request fixing this should close #5065 and #4961

[EpicWink]

Also note that a solution to the above reproduction example is:

pip3 install sentry-sdk google-cloud-storage 'urllib3<1.25'

[Freso]

There’s already a PR in the works: https://github.com/kennethreitz/requests/pull/5063

[EpicWink]

To those watching, as mentioned, we're blocked on urllib3 v1.25.2

[sethmlarson]

@nateprewitt FYI 1.25.2 will be released very soon, I would recommend in addition to disallowing 1.25.0 also disallow 1.25.1?

[rkooo567]

Our CI pipeline starts to get an error [integration_py3_docker_metric] 19-04-29:10:26:57 ERROR [clipper_metric_docker.py:127] Failed to parse: http://localhost:44328/api/v1/series?match[]=clipper_mc_parse_time_ms_sum from April 22nd, from when urllib3 version 1.25 was released. Do you think this is related to this issue?

[EpicWink]

@rkooo567, have you tried running the CI with the additional requirement urllib3<1.25?

[rkooo567]

@EpicWink Yes. And it seems like it resolves an issue. I also found out urllib3==1.25.2 also resolves the problem.

[sethmlarson]

urllib3 1.24.3 has been released which fixes only the CRLF injection issue for 1.24.X users.

[plowman]

Here's a possibly dumb question: why does requests restrict urllib3 to be < 1.25? Since many other pip dependencies are going to continue to increase their minimum allowed urllib3 version, it seems like this is going to guarantee two things:

1. Every minor version bump in urllib3 will break many projects which depend on requests (e.g. anyone who is using the major Google or Microsoft Azure packages, among many others).
2. Every minor version bump in urllib3 will then require a new release of requests to allow the new version of urllib3.

Does urllib3 make breaking changes that often that we're worried about just trusting their versioning? Or is there another concern?

[yjqiang]

@plowman https://github.com/kennethreitz/requests/issues/5080 Looks like the update to version 1.25 would make requests start up much slower.

[Freso]

Based on the number of references to this issue in other projects’ trackers, I’m sure there are a lot of other project maintainers that would appreciate a resolution to this sooner rather than later… :) (Pointing it out since issue references don’t trigger e‐mail notifications.)

[tucked]

+1 because it aggravates problems caused by Pip's lack of a dependency resolver in some cases: pradyunsg/zazo#14

[prometheanfire]

If you think that's fun, look at all the things that use requests and can't update urllib3. (we do some manual checking)

http://logs.openstack.org/36/658636/3/check/requirements-tox-py27-check-uc/48d2334/job-output.txt.gz#_2019-05-14_06_33_55_887702

[nateprewitt]

Resolved with #5092, release is up on pypi now. Thanks again @EpicWink