Use copier instead of cookiecutter

[GenevieveBuckley]

This PR swaps copier for cookiecutter.
It is a fully working implementation that people can try out (as suggested by @jni, see context below)

napari/napari#6122 by @jni

Consider using copier instead of cookiecutter #6122

Some folks from the scientific Python ecosystem seem to like it.

One thing I like is that it has built-in support for updating projects when the template is updated: https://copier.readthedocs.io/en/stable/updating

Apparently cruft does this for cookiecutter templates but that seems like a more complex tool chain since it's not built into cookiecutter.

I don't have a strong opinion here, just want to share something I came across that could be interesting to implement, since updating downstream projects is something we have needed a lot of.

PR to the original cookiecutter repository: napari/cookiecutter-napari-plugin#165

Closes #2
Closes #3

[tlambert03]

in case there's anything in here that might be useful to this effort, I had a copier template for napari plugins that I was working on a while back here https://github.com/tlambert03/napari-plugin-template
might be some patterns in there that are worth using. (the testing patterns in there might be useful too)

[tlambert03]

I see there's a discussion of pytest-copie ... that was more or less the goal of these lines:
https://github.com/tlambert03/napari-plugin-template/blob/main/tests/test_generate.py#L15-L61

see also, there was a dream at one point to use that template for an npe2 create command, see original PR here: napari/npe2#225

but, I closed that cause... ya know

[jni]

@GenevieveBuckley we need to get tests passing but repo permissions should be fixed.

[jni]

Bah, I've made a mess of things, got too excited by Draga's "placeholder" comment. 😅 Which was spot on though. I think the last push should fix the tests. But for now it's bedtime. 🤞

[jni]

Only comment I haven't addressed is @DragaDoncila's setup.cfg comment. @DragaDoncila is there any non redundant information in the setup.cfg? ie can we just delete the file in the template, or is there still metadata to be ported across?

[GenevieveBuckley]

Is there any non redundant information in the setup.cfg? ie can we just delete the file in the template, or is there still metadata to be ported across?

I checked line by line before removing template/setup.cfg.jinja from the repository with git. I did not see any information that wasn't already in pyproject.toml (or that we didn't need at all, like test dependencies that are not required for plugins).

[GenevieveBuckley]

Love the placeholders (thanks Draga!)
Just one question remaining: #1 (comment)

[GenevieveBuckley]

Closed in favour of #7