This same idea can be applied to any directory structure, and one that I'm keen to try next is AWS Lambda functions. AWS themselves have a sort of templating tool that gives you 1-click setup from templates (CloudFormation YAML embedded in links).
CloudFormation is a very verbose form of Infrastructure as Code (IaC) which can make it difficult to read at a glance compared to a framework built on top of it, such as the Serverless framework.
Some examples I've come across:
shows how to use
tox alongside a Serverless framework Python Lambda, though the Dockerfile,
sls.sh are all way too much icing on the cake to me.
- The more config, the more you have to maintain: keep Serverless simple!
- This was last updated 4 years ago and it shows.
cookiecutter-fastapi-serverless shows a FastAPI Serverless service: now this is more like it. If I wanted to try out the popular library this is how I'd start.
This brings good package management techniques to AWS Lambda packaging, and then takes care to exclude the packaging artifacts from the build.
I'd question whether a
setuptools-scm-style version control based exclusion policy is better than the long list of excludes in the
serverless.yml(is this possible?)
The YAML config includes a security policy to 'block public access' to prevent unintentional S3 leaks and discards logs after 2 weeks (not really something you'd do in an industrial deployment).
This library also fails its tests if any less than 100% code coverage is reported (yet doesn't badge the coverage...) I'd relax that a bit myself. Unclear if this is used in real life.
has an odd layout: a
vendor/ directory for "an existing vendored dependency" (?),
and deploying to AWS Lambda with a Python framework called Chalice. Not keen on this.
Much like with the Python package templates, none of these examples provide what I want, so I'll look into creating my own bespoke template.
This part is still being written, please check back again later...
If you enjoyed this series or you have a nagging question with something I did, let me know your thoughts on Twitter! @permutans
This post is the last of Package templating, a series covering how to generate a skeleton for a Python package with minimal barrier to setup with best practices like linting, pre-commit hooks and tests on CI.