Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
OpenSSL 1.0.2 Shared Library missing #855
I get the following traceback from my Lambda function when importing flask-ask:
Zappa should fall back on OpenSSL 1.0.1, the latest available on Lambda, or bundle the 1.0.2 shared library with the deployment package.
Lambda execution fails with the above traceback.
Yeah, so this is the result of the change that now checks package version in addition to package name.
Not really sure what to do about this: Revert behavior? Add a fixed
Keeping in mind that Just Working^tm is a Zappa design requirement.
Issue is that with a version that is not in lambda-packages, it will assume that it's being packaged in an AMI compatible environment and will use the local binaries. Example from the content of a package done on a mac:
Maybe a warning as part of the packaging process to either use a version on lambda-packages or make sure the build is compatible with the lambda environment?
Yeah, so I believe what is happening is this:
Zappa < 0.41.3 used to ignore binary package versions when pulling from lambda-packages or PyPi manylinux. This was bad. e.g. flask-ask depends on pyOpenSSL which in turn depends on cryptography>=1.7, which will download the latest version locally, i.e. cryptography 1.8.1. However, once you did deploy, you would instead pull 1.4 from lambda-packages and package that into your zappa deployment.
Zappa 0.41.3 now looks at the binary version when pulling from lambda-packages or PyPi manylinux. That means that the version of cryptography that zappa will package in your specific app here would be 1.8.1. That version, unfortunately, doesn't exist in lambda-packages, and by nature of crypto there is no manylinux version for it either (more details here: https://cryptography.io/en/stable/installation/#static-wheels)
A: I reckon Zappa should not force everyone to package crypto if they don't need it. In this case it is now necessary to specifically include cryptography==1.4 in your application if it depends on it (with zappa 0.41.3+). Yes it was nice that it "worked" in older versions, but it kinda worked for the wrong reasons.
B: If we reckon Zappa should package cryptography for everyone then we can include it in the requirements.txt of Zappa.
Either way a good idea might be for someone to update lambda-packages with newer cryptography (1.8.1) for both python 2.7 and python 3.6.
@Miserlou any preferences on above?
Working for the wrong reason is better than not working for the right reason. I think we should use the Lambda-compatible version of the desired package no matter what if possible to avoid these errors, but give a warning during packaging if the versions are different.
referenced this issue
May 16, 2017
@nikbora looking at my scrollback... I'm an idiot :) I forgot to do a