Should we mandate cruft or provide it as a option?

[ESKYoung]

cruft is a Python package that lets you update projects built from a cookiecutter to the cookiecutter's latest version.

In the next release (see PR #33), we'll be supplying some barebones instructions in README.md on how to implement it after your first commit. However, this requires repeating the prompt entries you just made to get it up and running.

However, you can call cruft directly from command line (once you have it installed). It produces the same prompts as cookiecutter, but also creates the necessary cruft files. Note there are limited install options (i.e. in a Python virtual environment), whereas cookiecutter can be installed system-wide.

An alternative is to create a Jinja templated version of cruft.json so that it's present in all generated projects, and then up to the user to decide if they want to use it.

Thoughts welcome!

[ESKYoung]

I had a think around creating a templated version of .cruft.json, but realised a few issues. We can't (easily) get the commit hash the user AFAIK without adding a dependency (see this issue on cookiecutter, for example).

I'm against doing this, as cookiecutter can be installed in many ways (Homebrew, APT, pip), but adding a dependency would limit these options. Of course if we mandate cruft, we would be reducing the installation options in any case.

We could hack a workaround, but it wouldn't be universal, given users can define the commit or branch to use when they call cookiecutter.

Grateful for thoughts.

[ESKYoung]

To note — seems cruft has now been added to Homebrew so (for MacOS and Linux users at least), you should be able to system-wide install it! 🎉

Homebrew formula: https://formulae.brew.sh/formula/cruft#default