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:
cookiecutter-serverless-aws-lambda
shows how to use tox alongside a Serverless framework Python Lambda, though the Dockerfile,
Makefile, Pipfile, setup.py, setup.cfg, and 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 theserverless.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.
cookiecutter-lambda-function
has an odd layout: a bin/ and 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.