{"errorMessage": "Unable to import module 'app'"}

This error could be related to this issue https://github.com/awslabs/chalice/issues/105 My app.py is importing a 3rdparty module like

from chalice import Chalice
from empythy import EmpathyMachines;

that I have successfully installed via pip install --upgrade -r requirements.txt as explained in the related issue, but it seems it has not been deployed correctly by chalice on the lambda machine. My virtualenv looks like this

(env) admin@macbookproloreto:~/Developmemt/ParisiLabs/ML/tutorials/lambda-sentiment/env$ tree -d -L 4
.
├── bin
├── include
│   └── python2.7 -> /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
└── lib
    └── python2.7
        ├── config -> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config
        ├── distutils
        ├── encodings -> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/encodings
        ├── lib-dynload -> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
        └── site-packages
            ├── empythy
            ├── empythy-0.5.6.dist-info
            ├── nltk
            ├── nltk-3.2.1.dist-info
            ├── numpy
            ├── numpy-1.11.1.dist-info
            ├── pip
            ├── pip-8.1.2.dist-info
            ├── pkg_resources
            ├── scikit_learn-0.17.1.dist-info
            ├── scipy
            ├── scipy-0.18.0.dist-info
            ├── setuptools
            ├── setuptools-25.2.0.dist-info
            ├── sklearn
            ├── wheel
            └── wheel-0.29.0.dist-info

[jamesls]

As for numpy/binary file support I have a few ideas for how to making working with both C extensions as well as custom binaries easier.

I see two ways to go (maybe it’s worth doing both):

First one: Provide a hook into adding arbitrary data into the deployment zip file we send to lambda. That way as we’re adding files to the zip file we can give you a chance to inject any prebuilt binaries. I think that supporting a “on-build” hook would make this possible, something generic like:

#!/bin/bash
# This would be hooks/building-zip
# It would pass in several arguments:

ZIP_DIR="$1"
MY_PREBUILT_BINARIES="linux-binaries"

cp -r "$MY_PREBUILT_BINARIES/*"  "$ZIP_DIR/"

# If you wanted to, for some reason, you could also remove things from the deployed zip
rm $ZIP_DIR/unnecessary-file.py

chalice deploy would call the hooks/building-zip script if it existed.

This is probably more useful to address #42.

The second option is to try to leverage the manylinux1 wheels. I’m not exactly sure how to plumb this in, but many libraries are starting to provide manylinux wheel files (numpy, sklearn)

The latest version of pip let’s you override the platform/arch to use, so the idea would be to ask it to use manlinux wheels’s when building out the virtualenv to send to lambda. I’d have to experiment with this approach more to see if I could get it working, but the benefit of this approach would be that it would “just work”, you wouldn’t have to do anything (provided your 3rd party librarys have manylinux1 wheels).

[onurmatik]

Basically the idea to make this work is to compile the required non-python extensions in the same environment as the environment that Lambda runs, which is an Amazon Linux instance, and include them in the zipped package.

I don’t know how this can be integrated into chalice but here are 2 related links: http://stackoverflow.com/questions/34749806/using-moviepy-scipy-and-numpy-in-amazon-lambda http://www.perrygeo.com/running-python-with-compiled-code-on-aws-lambda.html