Reverse cookiecutter template generation

[Eibwen]

Feature request: Be able to reverse the template process, to be able to push updates "upstream" while being able to use the outputted files to apply those updates

Description:

Keeping templates up-to-date can be difficult. You very often cannot run the unprocessed templates in any of the output program (opening a {{ homepageName }}.html directly will generally just result in syntax errors)

So my thought is to:

1. (stretch) run cookiecutter with a special command: cookiecutter --uniqueData template.zip
2. (stretch) That should generate the output, but instead of using the cookiecutter.json, it will use unique strings as the values (option to use a dictionary?)
3. (manual) One can now open that output, and use programs to help update or reformat things
4. (request) With that modified output, you can run a command like cookiecutter --buildTemplate ./modified
5. And it would re-replace from the generated cookiecutter.json, back to the templating values

This is all to make updating templates easier. Alternatively you could take an existing product, and start replacing the values you want templated with a given unique dictionary of words and works with the syntax of your files as opposed to having cookiecutter syntax mixed together with it, then run this command to get the template syntax

[cjolowicz]

@Eibwen You could also take a look at retrocookie. It implements a naive approach to the problem, but it has worked quite well for my use cases. Unfortunately I don't get much time to work on it, but I do use it quite extensively, mostly to copy Dependabot PRs from a template instance to the template itself, but also to upstream actual features.

[Eibwen]

@cjolowicz Thanks for the comment! That looks like it fulfills what I want very well

I am curious if you've had a problem with substrings at all, like many of our templates have projectName and namespace, which often are a subset of each other (like namespace is corp.team and projectName is corp.team.GeneratorService). Or if one of the values is a number, like 1, where it might have many false matches. Or does the cherrypicking just avoid an excessive number of false matches so it works out well enough?

That was the main reason I proposed using generated/dictionary strings which can be crafted to avoid such issues