Mini evaluation of project templating system
Posted on 2023.02.17
Whenever I needed to create a framework for a new project, I always used Cookiecutter. Totally a default choice, isn't it? Well, last week, for the first time in my life, I had to create a cookiecutter template myself. Something not really complicated, it was a scaffolding of a standard Python package inside a monorepo. Since we have a monorepo, we have a dynamically composed CI pipeline and I wanted the cookiecutter to automatically add the new project to the CI config. Since this is not really a standard thing to do with a templating engine, I started looking deeper into the documentation of the project. This led me down a bit of a rabbit hole and to this post itself.
Here are some of my observations about Cookiecutter, as a completely outside person who has never contributed to the project. The project seems to be more or less abandoned. Last release on 2022.06.01, last commit in September 2022. The original creators have not committed anything significant since ~2019. There is a person who is trying to impersonate a czar and is trying to make either massive changes or sometimes pointless ones like tox -> nox migration because nox uses .py as config files XD. This person is trying to do this without any community support and is now discouraged because someone dared to oppose him. To be honest, it looks pretty bleak. Since we simply do not need Cookiecutter's template library for our needs, I started looking for an alternative project. There are few of them:
- cookieninja - fairly fresh fork of cookiecutter
- copier - written in Python, actively maintained
- Yeoman - Written in Javascript
Well, I'm not really inclined to try the cookienija - it's a really new project and it will take some time to mature. That's the main reason why I don't want to introduce it to the codebase at work. Yeoman - I deeply dislike JS and I will refuse to use tools written in this language if there is an alternative. Also, it doesn't make sense to force people to get an extra toolchain just for a single tool. Everyone already has pipx, so it really doesn't make sense to look at any other language than Python for such a tool. That's why I took the time to look at copier.
In terms of repository health, copier has (in brackets info for cookiecutter):
- Not that many stars on GH - 900 (cookiecutter has 18.9k)
- 15 open MRs, 3 of which are dependency bumps (cookiecutter has 70 oldest from 2016 and no dependabot set up)
- It is updated to run with py3.11 (cookiecutter up to py3.10 and I would assume that will be the status for a long time)
- For the past year, it has consistently averaged 4 commits per week (no active and consistent maintenance)
- Pretty decent documentation. It's up to date and fairly thorough. (Cookiecutter's documentation is terrible. They don't even have a proper tutorial, the link in the repo leads to an outdated version of the docs)
I am still evaluating the code features, but from the obvious ones:
- template variable config in yaml
- type support for config values (cookiecutter uses plain json, no type annotation or validation out of the box. Validation needs to be done as a pre-run custom hook...)
- It uses mypy, black, high test coverage, generally seems to use modern standards.
- You can upgrade projects to a newer version of a template! This could be a super useful feature for the evolution of scaffolding many projects. [1] I still need to check if it works for monorepo.
- Template files have a suffix so that linters and validators don't complain that the python files are invalid.
I hope this quote sums up the real intentions behind the tool: Although Copier was born as a code scaffolding tool, it is today a code lifecycle management tool. This makes it somehow unique. Most tools below are only scaffolders and the comparison is not complete due to that.
[1] | https://copier.readthedocs.io/en/latest/updating/ |