I’ve seen this anti-pattern scattered around plenty DevOps code, especially in AWS lambda functions:
from botocore.vendored import requests
Vendoring libraries like requests into other libraries like botocore is arguably an anti-pattern in general, but reaching in to botocore and importing it in your own code is definitely one. Here are some of the reasons:
- The maintainers may un-vendor it. This just happened! In newer versions of botocore you can still import requests but all that’s left are some bits of the error handling system. If you upgrade botocore your imports will still work but you’ll get errors when you try to use requests. Like this in version 1.13.15:
>>> from botocore.vendored import requests >>> print(requests.get('https://google.com')) Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: module 'botocore.vendored.requests' has no attribute 'get'
I saw an import like this running in an AWS lambda function a few days ago and it worked but was showing deprecation warnings. When AWS upgrades it’ll break entirely.
- The vendored version may be outdated and have security vulnerabilities that have been patched in newer versions. Even if maintainers realize there’s a vulnerability, if they know they’re not using a vulnerable module of the package they may still not upgrade. Unless you check every usage to ensure you’re not using vulnerable modules at the vendored version, you should assume you are.
- The vendored package may have been customized. This shouldn’t happen, but I’ve seen it in other packages plenty of times. Once the code has been copied into the repo it’s super easy for someone to tweak it for convenience. Vendored packages may no longer behave how you expect.
Instead of relying on botocore’s vendoring, add requests to your dependency chain like usual. Add a line to your
requirements.txt file or update your
setup.py. To package code with dependencies for AWS lambda functions, check out this. To add dependencies to your
setup.py check out this.
If this was helpful and you want to save time by getting “copy and paste” patterns for Cloud DevOps in your inbox, subscribe here. If you don’t want to wait for the next one, check out these: