Add 'package' command about zappa

[Miserlou]

I was thinking that it would be a settings entry for each function.

Although, to be honest, I think my longer term vision would be that non-APIGW lambda functions could simply be wrapped as decorators as a way to replace Celery, etc, so you could do something like

@zappa(event_source="ses:blah")
def mail(event):
    return True

or for scheduled events:

@zappa(timing="0 0 0 * * *")
def defrag(event):
    return True

and have these functions created and configured automatically with deploy/update.

But I've held off on implementing that since lambda scheduling can't be done via API/boto yet. Thoughts?

[ubiquitousthey]

I started a fork to add the package and/or upload functionality. I got stuck where I needed to figure how how to do the settings. The settings file really needs to change so that one can define most of the environment settings on individual functions with an additional handler setting. How do you see this working? I am thinking something like:

{
    "dev": { // The name of your environment
       "app" : {
         "s3_bucket": "lmbda", // The name of your S3 bucket
         ... // Various lambda attributes
         "app_function": "your_module.app" // The python path to your WSGI application function.
       },
       "my_function" : {
         "s3_bucket": "lmbda", // The name of your S3 bucket
        ... //Various Lambda attributes
         "handler": "module.function" // The handler for the lambda function
       }
    }
}

I think it would be pretty easy to handle both the old-style and new-style. If there is an "app" key in the dictionary, load as new-style, if not load as old-style.

Your thoughts?

[Miserlou]

Hi ubiquitousthey - thanks for bringing this up.

I think that might be over-engineering it a bit. I don't think an environment would have a both an app_function and a handler - just one or the other, with app_function taking precedent over handler. Does that make sense, or is there a scenario I'm missing?

[ubiquitousthey]

I have an system I am working on that will have a web component that I would develop with zappa/flask. It also will have a few lambda functions that get triggered by SES and a timer. I was thinking it would have a configuration like the one above.

In this case I was thinking one could issue:
zappa dev deploy or
zappa dev deploy app or
zappa dev deploy my_ses_handler

This could also be accomplished with an environment per function or app as well, and that could leave the format pretty much the same and simplify the changes to the code, but it would push toward environments that would result in command like:

zappa app-dev deploy and
zappa my_ses_handler-dev deploy

which would result in some uglier function and apig names.

Maybe the the idea would be to have one settings file per app or function?

[ubiquitousthey]

One zapp_settings file per function sounds reasonable.

The decorators sound interesting. I like being able to define the triggers in code. There might need to be a way to configure environment. One might have 2 SNS topics: one for testing and one for production. I suppose the precompile step could be used to load settings from a renamed json or py.

I think the lambda schedule is available now as a cloud watch event.
http://boto3.readthedocs.io/en/latest/reference/services/events.html?highlight=cloud%20watch%20event#CloudWatchEvents.Client.put_rule

You would have to call put_rule and put_target.

[Miserlou]

Ooo.. excellent find. Cool.

[Miserlou]

Keep-Warm using CloudWatch Events is now in Master.

[ubiquitousthey]

Cool. I'll create a PR for the settings-per-function idea as that moves me forward. I'll look at the decorator idea after that.

[Miserlou]

You are actually already be able to specify a different settings file using the '-s' argument.

[kpx-dev]

I think we should model this CLI similar to docker:
zappa build
zappa push
..etc

Each function can have its Zappafile settings

[Miserlou]

Thanks @michi88 for implementing this