Add 'package' command #61
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:
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.
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?
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:
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:
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?
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
or for scheduled events:
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?
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.
You would have to call put_rule and put_target.