Solvedcookiecutter How to update a project with changes from its cookiecutter?

Hi,

I maintain several personal cookiecutters, and I found that I spend a lot of time keeping projects in sync with updates on the cookiecutter.

I started trying a workflow to deal with this, as follows:

1. Every project I render is assumed to be versioned by git. In the project repo, there is a branch template, that contains the result of cookiecutter rendering, without any other changes.
2. Every cookiecutter renders a file .cookiecutter.json at the root of the project containing the original context used to render that project, in json format.
3. Every project has a Makefile containing at least an update-template target. This make target does the following:
   • Create a temporary checkout (via git worktree) of the template branch.
   • Use the stored context in .cookiecutter.json to regenerate the project on top of the temporary checkout, overriding previous content.
   • Commit the newly rendered project in the template branch.

This way, the template branch tracks the changes from the cookiecutter, and I can use git-merges into master to update the current project.

The key thing is that by using git merges, I can update template files that got havily modified in the project. Most of the time the merge is clean, but from time to time a conflict will arise, which is easily resolved.

I've used it for a while and works pretty well. There are at least a couple of pain points though, that could benefit from changes in cookiecutter upstream, which may be of independent interest.

1. The template I use to generate a .cookiecutter.json is a bit hacky. I'd like to do something like this:

   {{ cookiecutter | jsonify }}
   

   Would you accept distributing this jsonify as a default extension? I can provide the code in an other PR.

2. In order to get updates from the cookiecutter, the project stores its url in a _template field on its context. Right now, I hard-code this url in the cookiecutter itself. I would love to free my cookiecutters from hard-coding their url, That could be achieved if cookiecutter itself would inject a _template field into the context with the url used at the time of rendering. I submitted #774 to that effect.

Additionally, maybe a functionality like the update-template I described above could be moved into cookiecutter upstream. That would require some thinking, I guess...

Of course, any suggestions, or other ways in which a workflow like this could be better supported by cookiecutter would be very welcome!

Alternatively just use cruft https://cruft.github.io/cruft/

I'd like to chime in with a solution I came up with:

cookiecutter REPO_URL --output-dir .. --config-file .cookiecutter.yaml --no-input --overwrite-if-exists

• --output-dir .. allows us to run the cookiecutter in the repo root vs. the parent directory because cookiecutter will always render output in a child directory of the output-dir.
• --config-file cookiecutter.yaml will run the cookiecutter with the original inputs which are persisted to .cookiecutter.yaml in the repo root (this is generated by the cookiecutter).
• --no-input will skip the cookiecutter prompts.
• --overwrite-if-exists will replace our previous cookiecutter output with the most up-to-date output.

Err, nobody's asking for a magic, do-what-I-mean solution. This is a three-way merge. You do the merges you can, and then flag the conflicts for human review. This general concept is already implemented in multiple other places, including Debian for config files in /etc, and more specifically here, other projects built on top of cookiecutter (like cruft: https://github.com/timothycrosley/cruft/). It's fine for the project to decide this is out of scope. But it's clearly possible, because this problem is being solved elsewhere.

Would have a need for this also. What's needed for this to move forward? Any opposition from the cookiecutter maintainers for integrating a solution to this into cookiecutter itself? Because at the moment, many people seem to be reinventing that wheel.

Assuming there's no opposition to the idea of adding this feature, do we still need to discuss the approach to take here, or would we be at the stage where a pull request would be the best way to move this forward? Thanks!

(One implementation of this feature is here: https://github.com/senseyeio/cupper)