CookieKeeper: templates as reusable, enduring artifacts rather than project generators

(This is a feature request / design discussion rather than a bug report, so, template omitted.)

Cookiecutter’s primary use seems to be at the point where one generates a new project. However, the files that Cookiecutter templates generate (tox.ini, travis.yml, etc) frequently need to be updated over time, and best practices evolve, so templates rarely stand still.

The most illustrative example I can think of for this is https://github.com/audreyr/cookiecutter-pypackage/blame/master/README.rst - features like auto-release to PyPI were added after the template was originally created, so projects initially created by that template would miss out. Projects may want to migrate from bumpversion to versioneer to towncrier. New projects might want to start off with flit rather than setup.py, but migrate when they get bigger or need more advanced features.

I maintain dozens of projects which already exist, and sadly few (if any) were originally created using these templates. But I want to stop submitting individually-reviewed PRs to do stuff like dropping python 2.6 (or 3.3) in the travis.yml, the tox.ini (etc) of 17 different projects. I want to have one master template and then just re-cut the cookies across the 25 or so repos on https://github.com/twisted.

I don’t know exactly what cookiecutter needs to do in order to support this workflow. Perhaps this is already possible with some sort of discipline around how these files are written and maintained; so my main request here is that the docs examine this use case, and explore how to deal with the passage of time, and the updating of 1 template across N projects. But I believe that in many cases some kind of merging support is required; for example, given the case of PyPI uploads, if some modification needs to be made to that workflow, the travis secrets need to be maintained in the travis.yml, so that needs to be parsed and re-emitted.

[pydanny]

This is something that was considered from the first day the project launched. In fact, myself and Audrey have cooked up in-house tools to “kinda sorta” make this happen for ourselves on various projects. But our requirements are specific for us only, and open sourcing these tools doesn’t make any sense.

To make a tool of this sort usable by others is an enormous amount of sophisticated work. It’s the kind of effort that involves at least a hundred hours of work. We’ve wanted to do this, but when we asked the Cookiecutter community (including companies with deep pockets) if they were interested in our working on this kind of thing, it fell on deaf ears. While some individuals voiced interest in having such a feature or submitting pull requests, no one was willing to pull out the proverbial checkbook. Or even escalate it to management.

To summarize: We want to do it but the core devs can’t invest the time to make it happen without appropriate funding.

[yajo]

FTR I’ve been recently contributing with @pykong to the upcoming 3.0.0 release of Copier, to support using it as a project maintenance tool instead of just a project bootstrapping tool, out of the box.