lambci / docker-lambda

Docker images and test runners that replicate the live AWS Lambda environment
MIT License
5.83k stars 431 forks source link

python 3.7 requests module inconsistency on aws #279

Open v0lat1le opened 4 years ago

v0lat1le commented 4 years ago

lambci/lambda:build-python3.7 container contains requests module while AWS python3.7 execution environment doesn't seem to. This causes our build system to skip bundling requests module along side the lambda code.

The quick workaround we used was

import sys
from botocore.vendored import requests
sys.modules['requests'] = requests

Some info on past and upcoming changes to requests package within AWS env https://aws.amazon.com/blogs/compute/upcoming-changes-to-the-python-sdk-in-aws-lambda/ with might be relevant here

mhart commented 4 years ago

Many many packages and binaries and libraries exist on the build-* containers that don't exist on the runtime containers (or Lambda itself). This is the nature of the build containers – they need software like gcc, etc to make sure that ppl can build their software. As well as python packages like AWS SAM CLI, etc so that ppl can deploy from their build containers.

How are you building your Lambda functions? Are you using sam build?

v0lat1le commented 4 years ago

Ah, that makes perfect sense. I think there's a bit of confusion on our part as to the purpose and distinction between the run and build containers.

For the record we are trying to do docker run -v ${PWD}:/var/task lambci/lambda:build-python3.7 bash -c "pip install --prefix=dist .; cd dist/lib/python3.7/site-packages/; zip -r9 ../../../${PWD##*/}.zip ." to only include packages that will not be available within the execution environment.

Thank you!

mhart commented 4 years ago

pip is a little bit annoying in this regard with the way it deals with packages installed at the system level. I'd use pipenv/virtualenv instead – I think that's a better way of creating a reproducible environment