-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Latest release of requests causes urllib3 to throw an error #6443
Comments
Hi @Rach81, This is unrelated to Requests. You're installing a version of urllib3 that's incompatible with the version of Boto3 bundled in your runtime. You'll either need to pin your urllib3 dependency to |
I'm not directly installing urllib3 anywhere. I fixed the issue by reverting to the prior version of requests from 4/26 . That was the only change I made. |
Upgrading Requests to 2.30.0 allows for the use of previously released urllib3 2.0. If you're using something like Prior to Requests 2.30.0, we actively blocked the use of this urllib3 version. Now that this is no longer happening, you may need to constrain your dependencies for certain environments such as Lambda until they update to a newer version of Boto3. |
+1 |
Same issue - worked in the morning, stopped working in the afternoon. could be related to vs-code update. Any help would be greatly appreciated |
This comment was marked as off-topic.
This comment was marked as off-topic.
I'll try to further clarify the comments above since there's some confusion. The solution if you rely on one of the breaking changes with urllib3 2.0's release is to pin your dependencies to Depending on how you deploy/install your code, this may look something like: pip installation
requirements.txt
pyproject.toml
poetry dependencies
|
I see your point, but ultimately the solution is to pin an outdated version of something. Whether that's requests or urllib3... Unless I am misunderstanding something? |
urllib3 1.26.x is continuing to receive security updates for the near future. Pinning at the Requests level will block you from receiving security patches. The underlying issue is at the urllib3 level which ideally is where it's constrained. Otherwise, you're relying on Requests to implicitly be the barrier from other dependencies bringing in urllib3 2.0. |
File "/home/appuser/venv/lib/python3.9/site-packages/streamlit/runtime/scriptrunner/script_runner.py", line 565, in _run_script |
Look like new version of requests is pulling newer versions of urllib3 which are not comptible with botocore. Ref: boto/botocore#2926 Ref: psf/requests#6443 Ref: urllib3/urllib3#2168
Look like new version of requests is pulling newer versions of urllib3 which are not comptible with botocore. Ref: boto/botocore#2926 Ref: psf/requests#6443 Ref: urllib3/urllib3#2168
downgrading to V2.29.0 fixed the issue as of now. |
The recent update of urllib3 completely broken the world - urllib3/urllib3#2168 - boto/botocore#2926 - psf/requests#6443
Hi guys any news about the requests and urllib dependencies? |
@mase-git There isn't anything to be solved in Requests or urllib3. Requests 2.31.0 works with both major versions of urllib3. If you're using dependencies that don't support the breaking changes in urllib3 2.0, you can pin to urllib3 1.x as detailed when this issue was first opened. That will resolve any incompatibilities. |
I have an issue that doesn't look directly related based on this thread, but it is also fixed by forcing https://gitlab.com/fdroid/sdkmanager/-/jobs/4372611166
|
They say 1.26.x will be maintained for a while. To fix, someone needs to figure out what the exact problem is as shown in: psf/requests#6443 (comment) I suppose there will need to be some change related to the urllib 2.x migration, but it is unclear to me which. The usage of requests in fdroid/sdkmanager is quite simple. https://urllib3.readthedocs.io/en/latest/v2-migration-guide.html
I am using boto3-1.26.140 and botocore-1.29.140 with python 3.9, no requirements.txt are defined. In addition, if no requirements.txt was specified and dependencies didn't solve it automatically with no forcing versioning, the problem should be the library dependencies binding. So, it should be a problem of the library. Generally, industrial applications trust on libraries for the stable of the latest versions, what happened with requests and urllib compatibles? There is no excuse about old dependencies ends to be compatible due to the "unstable" old version. Am I wrong? |
I don't know if this has any value to the content of this thread. But I just wanted to say that today, as of june 6th my code suddenly stopped working. Your solution of: |
I am still getting this error when running lambda. [tool.poetry.dependencies] |
I got this error today after re-deploying my lambda function
Error
|
I have managed to resolve this issue. This can be resolved in two ways: |
could you please explain me on discord a way to pin your dependancies,since i'm in need of a program that gives me this specific error(and i need it to get my google drive backup of whatsapp since i lost everything) [i] Searching... Requesting access to Google... |
You should use pip-tools or poetry to record dependencies. |
Resolving along with #6432 and locking it to avoid losing context with further comments. Please read #6432 (comment) if you still have questions after reading this thread. Of particular note here:
|
A previously working lambda function started throwing this error.
{
"errorMessage": "Unable to import module 'app': cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_' (/var/task/urllib3/util/ssl_.py)",
"errorType": "Runtime.ImportModuleError",
"requestId": "30bf7245-a58f-4192-81e3-5d122fb31d11",
"stackTrace": []
}
While trying to debug the issue, I narrowed it down to being a problem with requests (new release yesterday 5/3/2023). I then tried referencing the prior release which fixed the problem and my function worked as expected again.
To reproduce the error.
requirements,txt > requests- uses the latest release (2.30.0) and causes the lambda function to throw the error above.
requirements,txt > requests==2.29.0 - uses the prior release (2.29.0). With this release the error above no longer occurs.
The text was updated successfully, but these errors were encountered: