-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Remove vendored version of requests #1829
Conversation
The exceptions are left in place for backwards compatibility.
Codecov Report
@@ Coverage Diff @@
## develop #1829 +/- ##
===========================================
+ Coverage 92.2% 92.55% +0.35%
===========================================
Files 53 53
Lines 9958 9958
===========================================
+ Hits 9182 9217 +35
+ Misses 776 741 -35
Continue to review full report at Codecov.
|
HTTPSConnectionPool, | ||
connection_from_url | ||
) | ||
|
||
from . import exceptions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems odd:
- vendored
requests
are removed - vendored
urllib3
is removed - but vendored
urllib3.exceptions
remains?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re: "for those who used these features"
I think perhaps this can be worked around by e.g.:
# vendored/__init__.py
import requests
which would ensure that user can still from botocore.vendored.requests.urllib3.exceptions import X
In any case, if someone were to catch e.g. HTTPError
, it needs to be same HTTPError
is thrown in the dependencies, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a little strange, but let me provide a little more context on this. In earlier versions of botocore
we leaked exceptions from requests
which meant that in some cases users may have needed to import an exception class similar to what you show:
from botocore.vendored.requests.urllib3.exceptions import X
In the migration to urllib3
we generally followed the exception structure in requests
/urllib3
and mapped them to our own exception classes. Leaving the exception classes is simply to ensure users using a line similar to the above will continue to work (as closely as possible) and avoid a hard import error.
We have considered the latter suggestion but as we no longer depend on requests
it's a little more tricky than just doing the import as requests
may or may not be present. We also have no control over the version of requests
which leaves the possibility for something to change in requests
breaking the SDK (though this is probably unlikely). I know that requests
did a similar change when they removed their vendored urllib3
but things are pretty different here since we no longer depend on requests
.
pip install requests Code to download file from IBM cos bucket to local storage using serverless function: import requests cos = ibm_boto3.resource(service_name='s3', try: except Exception as e: Error: DeprecationWarning: You are using the post() function from 'ibm_botocore.vendored.requests'. This is not a public API in ibm_botocore and will be removed in the future. Additionally, this version of requests is out of date. We recommend you install the requests package, 'import requests' directly, and use the requests.post() function instead.\n DeprecationWarning\nTraceback (most recent call last):\n File "/action/1/src/exec__.py", line 43, in \n from main__ import main as main\nImportError: cannot import name 'main' from 'main__' (/action/1/src/main__.py)\n" |
Seems to be a separate repository - Might want to file the issue there. |
@jamesls since Python 3.8 has already been released, could we merge this a few days earlier than planned? |
Might be good to update this: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-lambda-function-code-cfnresponsemodule.html |
PR #1829 * remove-vendor: Update tests to not rely on vendored requests Remove vendored requests
Merged! We'll follow up with the docs team to get that code snippet updated. |
Please update headline to also state |
We're now seeing this error now when using
I have a PR open on the repo behind the PyPI to fix this but hasn't gotten a response yet: |
Is python 3.8 available for lambda now? We do not see it on the console? |
+1. I believe this happens because in my case the code updates botocore using pip install from code, to be able to use updated API features. Probably the botocore version in standard Lambda environment is not updated and would not suffer from this issue, but then we would not be able to use the newer features. |
I followed the doc https://aws.amazon.com/blogs/developer/removing-the-vendored-version-of-requests-from-botocore/ and combining the requests to "pip install requests awscli boto3 pytest --upgrade" will that works? For me, Jeankins job was successful and the same issue while invoking REST call. Any idea? Thanks in advance! |
Won't this break lambda functions that's using vendored? |
Would be good to provide a migration guideline for Lambda breaking change, so that people can use |
@meshuga have you tied the direction from "How to fix your code"? If so, what is your experience? |
@chrisdlangton I did look at the How to fix your code but the approach is not acceptable for me since it degrades the ease of usage of AWS Lambda. I have code in AWS Lambda without any dependencies and don't want to add any library for sake of making HTTP requests, since #1829 (comment). |
This is pretty bothersome. I have a number of very small Lambdas that currently have zero dependencies because they're able to make use of the vendored requests lib, and now I'm going to have to do full package deploys just to update them when I could have used the AWS Console's editor previously. |
I'm not sure what the current story is on project maintenance for
Example lambda using urllib3import urllib3
http = urllib3.PoolManager()
def lambda_handler(event, context):
r = http.request('GET', 'https://example.org/')
return {
'statusCode': r.status,
'body': r.data,
} Side note: |
cfn-response module still uses vendored.requests |
As advised, we have removed - from botocore.vendored import requests - and using - import requests. But we are getting the below warning. WARNING - botocore.vendored.requests.packages.urllib3.connectionpool - Connection pool is full, discarding connection: trp-usis-stage-us-east-1-mft-intermediariesanalytics-raw.s3.amazonaws.com We are using boto3 version 1.7.35. Do we have to upgrade our boto3 version too? |
Looks like the date was moved to Jan 2021 as per https://aws.amazon.com/blogs/compute/upcoming-changes-to-the-python-sdk-in-aws-lambda/. I have tried using this approach and found a few posts on AWS Forums and comments in the same blog but still doesn't work. While I appreciate moving the date out to Jan, 2021, those of us who would like to fix this problem right now are stuck because the layer approach doesn't work. |
Remove vendored requests from botocore boto/botocore#1829 Add constraint to ddt
Remove vendored requests from botocore boto/botocore#1829 Add constraint to ddt
Remove vendored requests from botocore boto/botocore#1829 Add constraint to ddt
Hello everyone, i am using cfn-response module with nodejs. Do i need to update anything? |
This PR removes the vendored requests from botocore.
NOTE: This PR is not going to be merged immediately. This is
being sent in advance so people can use this branch to test. The
planned date to merge this is 10/21/19.
I've left the exceptions for requests and its vendored urllib3 so that anyone
that needed to catch these exceptions (that we used to leak) will not be broken.
A bit of history on this change.
The original version of botocore, before GA, had requests as a direct
dependency. In the leadup to GA, we decided to vendor the requests library
at the request of package distro maintainers. We frequently needed the latest
version of requests, and package maintainers weren't able to immediately
upgrade requests globally, given it's popularity and widespread usage.
The 1.0.0 GA release back in 2015 continued to keep the vendored version of
requests in botocore.
Four years later, things have changed. First, the requests feature set
stabilized. We no longer need to constantly be pulling in the latest version
of requests for new features. We also kept needing more low level
functionality that was more accessible in urllib3 (which requests depends on).
Last year we decided to put in an abstraction over the http library we use so
that we could migrate from requests to urllib3 while also allowing pluggable
http clients.
Once this change was merged last year, botocore no longer uses the vendored
version of requests, but we decided to keep it in place instead of immediately
removing it. Yes, it is a vendored library, and even namespaced as such, but
it's still technically possible to import the vendored library of requests and
use it directly in your code. This vendored library was never something we
publicly documented or ever supported people directory using.
We wanted to give people adequent time to migrate away from this usage
before removing the vendored requests entirely.
Timeline of the deprecation
This deprecation has been in the works for a while, here's a timeline of
everything:
also added support for pluggable HTTP endpoints, and fixed all of the leaked
exceptions from our vendored requests. The vendored requests was left in
botocore, but our code is no longer using it.
DeprecationWarnings
to any usageof botocore's vendored requests library. By default nothing is printed, you
have to enable deprecation warnings to see this message.
whenever botocore's vendored requests library is used.
Additionally, python 3.8 is being released on October 21st, 2019, and there
are changes that will break our vendored version of requests. This means that
we need to do something or else python 3.8 will not work with botocore.
If you tried to use this deprecated package, the warning looks like this:
How to fix your code
If you were previously using our vendored version of requests, you can migrate
away from this by installing requests into your python environment and
importing requests directly:
Before
After
Please let us know if you have any questions or concerns.
Related issues: