Giters

getsentry / responses

A utility for mocking out the Python Requests library.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

responses==0.23.2 breaks pip resolution with popular packages

jmsanders opened this issue · comments

commented

Describe the bug

This may ultimately end not being a responses issue (or a "just pin to the old version" answer), but I wanted to call to your attention that responses==0.23.2 substantially changes pip resolution results when installed alongside other popular packages.

Given:

psf/requests#6432
and boto/botocore#2926

Perhaps #652 is premature?

Additional context

No response

Version of responses

0.23.2

Steps to Reproduce

docker run -it python bash -c "pip install responses==0.23.1 boto3"

Results in:

Installing collected packages: types-PyYAML, urllib3, six, pyyaml, jmespath, idna, charset-normalizer, certifi, requests, python-dateutil, responses, botocore, s3transfer, boto3
Successfully installed boto3-1.28.10 botocore-1.31.10 certifi-2023.7.22 charset-normalizer-3.2.0 idna-3.4 jmespath-1.0.1 python-dateutil-2.8.2 pyyaml-6.0.1 requests-2.31.0 responses-0.23.1 s3transfer-0.6.1 six-1.16.0 types-PyYAML-6.0.12.11 urllib3-1.26.16

Whereas:

docker run -it python bash -c "pip install responses==0.23.2 boto3"

Will backtrack through many, many versions of boto3 and eventually land on:

Installing collected packages: types-PyYAML, urllib3, six, pyyaml, jmespath, idna, docutils, charset-normalizer, certifi, requests, python-dateutil, responses, botocore, s3transfer, boto3
Successfully installed boto3-1.7.84 botocore-1.10.84 certifi-2023.7.22 charset-normalizer-3.2.0 docutils-0.20.1 idna-3.4 jmespath-0.10.0 python-dateutil-2.8.2 pyyaml-6.0.1 requests-2.31.0 responses-0.23.2 s3transfer-0.1.13 six-1.16.0 types-PyYAML-6.0.12.11 urllib3-2.0.4

Expected Result

Pip resolution succeeds with recent versions of other packages.

Actual Result

Pip resolution takes a long time and installs very old versions of other packages.

commented

@jmsanders responses pins requests >= 2.30, for the reason of compatibility between 2.29 and urllib 2.x

however, I think it is user issue if some lower boundaries are not pinned. In this case boto should be pinned to >=x
then pip resolver will either fail or install the right revision of responses for you.

commented

Not sure if have to pin urllib3>=2 though. As it is allowed to use requests>=2.30 with urllib3<2

Note 2.30.0 is the requests version that added support for urllib 2.0.

https://github.com/psf/requests/releases/tag/v2.30.0

From release notes: Users who wish to stay on urllib3 1.x can pin to urllib3<2.

commented

As a note there is issue #657 and PR #659 which are both related to this.