Add support for than app.py

[jamesls]

The initial version of this framework only has support for an app.py file. I always envisioned being able to support more than this, while still trying to keep things small. What I had in mind:

• You can either have a single app.py or, create an app/ directory.
• The app/ directory must be a python package (__init__.py).
• You still have to have an app object defined in __init__.py.
• Everything in app/ will be included in the zip file distribution, including non python files.

This will allow you to split your app into multiple python modules as well as include data/config files with your app.

Keep in mind, the source code analyzer will likely need to be updated as well to handle more than just an app.py file.

[bmccary]

I'm looking forward to this feature.

[mannysz]

Awesome feature. Basically you can handle other files by using boto3 with S3 buckets (for the configuration files, for example), but it would be awesome if chalice could handle it (deploy other files in buckets) by itself (despite it would conflict with the intention of being a micro framework).

[dkotik]

Please, please make this work!

[njsnx]

What about allowing multiple files to be split up into multiple Lambda functions - There is requirements for multiple functions for one API project that this would fulfill

[jbarratt]

I really liked the idea of chalice, but wanted to use it with a more complex package than I was comfortable wedging all into app.py. It was a little hacky to get working, but it's a usable workaround. Using a directory structure like so:

    mychaliceapp/
    mypackage/                       #regular python package tree, with tests, dependencies, multiple mods, etc
        mypackage/__init__.py
        tests/
        setup.py

a python setup.py sdist in my custom package creates a dist/mypackage-0.1.tar.gz. So in the chalice app, ../mypackage/dist/mypackage-0.1.tar.gz can be added to requirements.txt.

To get new code into the lambda deploy is a little tricker since it tries to use the 'replace app.py in the zip file' strategy. So a little refresh_deps.sh script is helpful:

#!/bin/bash

pushd ../mypackage/ && python setup.py sdist && popd
source .chalice/venv/bin/activate
pip uninstall -y mypackage
rm .chalice/deployments/*.zip

So when changes are made in mypackage, I just run ./refresh_deps.sh and it redeploys with them pulled in.

[MarkusAholainen]

I like the idea of Chalice. Keep on the good work.

Chalice should follow as closely Flask as possible to enable running the same project in local (Flask mode) for convienient development and debugging. Please keep this in mind and run your projects as Flask apps and see how easy/difficult that is . Alternatively provide a local mode with standard Python debugging in mind. pdb.set_trace() is a good starting point.

When the single app.py limitation will be fixed?

[jamesls]

Sorry for the delay on this, I've been bouncing some ideas from #56 and trying out a few prototypes of this feature. I've also been chatting with the rest of the python sdk team on this to get more feedback.

While the find_packages('.') approach seems to be the most generic solution, I'm finding that it has a few undesirable characteristics:

• It's including things I don't want it to. I generally don't want to include every single python file. Including every python file means that I have no way to control what I'm including in the deployment zip file. I'll typically have:
  • python scripts for configuring additional resources (ddb tables, s3 buckets, etc)
  • tests code (usually in tests/ or sometimes just test_app.py if it's simple enough.
• It's not including all the things I want. I still need a way to include non python files. Anything from .json config files, or misc binary assets.

Now, both of those problems can be solved with an explicit include/exclude list, but I would have to generate those in my common case (where I have tests/, and misc scripts/ files).

The idea that seems to be working out the best is to have a dedicated directory, something like chalicelib/ (not tied to the actual name), that has a simple rule: if the directory exists, anything (recursively) is included in the deployment zipfile.

I have a proof of concept for this, but I'm interested to hear what others think.

/cc @kyleknap @JordonPhillips

[jamesls]

PR: #146

[jamesls]

#146 is merged. I'll get a release out soon. Please try it out and share any feedback you have.