-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add 'package' command #61
Comments
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. Your thoughts? |
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. |
Ooo.. excellent find. Cool. |
Keep-Warm using CloudWatch Events is now in Master. |
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. |
You are actually already be able to specify a different settings file using the '-s' argument. |
I think we should model this CLI similar to docker: Each function can have its Zappafile settings |
Thanks @michi88 for implementing this |
It could be useful to have Zappa be a more general Lambda utility - for instance, for automatically using lambda-packages and minifying, etc.
The text was updated successfully, but these errors were encountered: