"module initialization error" message for barebones flask app

[mgalvey]

This might be a duplicate of #107. I've been trying to get a minimal deployment (barebones generic Flask app) to work, using the example embedded into the readme, but I'm ending up with a blank response and an error message in CloudWatch when I try to hit my live API Gateway URL: "module initialization error: Attempted relative import in non-package"

I've tried to mimic the animated gif example as closely as I could, just to make sure I wasn't hitting some edge case of incompatibility with my "real" code.

I've been using a minimal install of CentOS in a VM for these tests, and I've copied the steps I took below. Am I missing something obvious here, or is there some bug in Zappa causing this to occur?

root@localhost ~/test# zappa --version
0.18.1
root@localhost ~/test# for file in (ls)
                           echo $file: & cat $file
                       end
app.py:
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

if __name__ == "__main__":
    app.run()
zappa_settings.json:
{
    "test1": {
       "s3_bucket": "4242-zappa",
       "app_function": "app.py",
       "delete_zip": false,
       "parameter_depth": 1,
    }
}
root@localhost ~/test# virtualenv venv
New python executable in /root/test/venv/bin/python
Installing setuptools, pip, wheel...done.
root@localhost ~/test# source venv/bin/activate.fish
(venv) root@localhost ~/test# pip install flask > /dev/null ^ /dev/null
(venv) root@localhost ~/test# ls venv/lib/python2.7/site-packages/
click/                flask/                        itsdangerous.pyc       MarkupSafe-0.23.dist-info/  setuptools/                   wheel/
click-6.6.dist-info/  Flask-0.11.1.dist-info/       jinja2/                pip/                        setuptools-23.1.0.dist-info/  wheel-0.29.0.dist-info/
easy_install.py       itsdangerous-0.24.dist-info/  Jinja2-2.8.dist-info/  pip-8.1.2.dist-info/        werkzeug/
easy_install.pyc      itsdangerous.py               markupsafe/            pkg_resources/              Werkzeug-0.11.10.dist-info/
(venv) root@localhost ~/test# zappa deploy
Packaging project as zip...
Uploading zip (3.7MiB)...
  0%|                                                                                                                                       | 0.00/3.89M [00:00<?, ?it/s]
Scheduling keep-warm..
Creating API Gateway routes..
108it [00:14,  7.29it/s]
Deploying API Gateway..
Your Zappa deployment is live!: https://z02c6ub6x9.execute-api.us-east-1.amazonaws.com/test1
(venv) root@localhost ~/test# zappa tail
[1467133943052] module initialization error: Attempted relative import in non-package
[1467133969117] module initialization error: Attempted relative import in non-package
[1467133971806] module initialization error: Attempted relative import in non-package
[1467134028611] module initialization error: Attempted relative import in non-package
[1467134037963] module initialization error: Attempted relative import in non-package

[collingreen]

@mgalvey It looks like you don't have zappa installed in your virtualenvironment.

That is a current hiccup that can be hard to diagnose (since you probably have zappa installed OUTSIDE the environment). This happens because zappa includes a custom handler function that does all the api gateway <-> uwsgi magic and it needs to get deployed along with the rest of the lambda package, which comes straight out of the virtual env.

Adding to your example, try source venv/bin/activate.fish && pip install zappa, then you should be able to deploy.

[mgalvey]

Thanks @collingreen, that was definitely the problem. I had an additional issue to fix with my zappa_settings file (misunderstood what's supposed to go into the "app_function" key), but once I fixed that, I got a working deployment.

It would be a handy feature for Zappa to detect that it's being invoked using a global path rather than a virtualenv one, and warn the user. At the very least an explicit blurb in the readme explaining the need to install Zappa into your target virtualenv would be helpful. It wasn't obvious to me based on what's there now, and I imagine others might experience the same issue.

In any case, this issue can be closed. Thanks again for your help!

[collingreen]

@mgalvey completely agree! I've been collecting some common troubleshooting bits like this and will eventually put together a PR for some sanity checking (#78) and some more readme details.