idea: making this a cookiecutter

[jakob1379]

Hey there,

I am a frequent user of this great starting point for GPP (Good Python Practice :P ). Have you considered making this a cookie-cutter instead of the custom bash scripting for instantiating this as a new user project?

I would gladly give some time and effort to help you out with it, if it is of interest.

[carderne]

Good idea. I haven't used cookiecutter in ages, can it be done in a relatively unobtrusive way? I'd like to keep it non-compulsory to use cookie cutter, keep the repo clear and useful for people that aren't using that.

If yes and you're happy to do the lifting I'm happy to review a PR.

[jakob1379]

It will be obtrusive, so I will not recommend that, then.

I'll chew in this and see if I can come up with something. To my knowledge cookiecutter is still well and alive and commonly used.

[MCatskinandme]

Hi 👋,
What about doing it in a separate repo?
This is what the original inspirational project did with https://github.com/cjolowicz/cookiecutter-hypermodern-python.
I like the idea of the cookie-cutter too.

[carderne]

I'm not completely opposed, even if it is a bit obtrusive. I like the simplicity of the current repo, but maybe more people will value it is a cookiecutter?

iirc the main advantage of cookiecutter is that you can keep up-to-date with upstream. I'm not sure that's really useful here, as I don't see this repo changing very much?

[jakob1379]

I've been thinking about how to cater to both users who want a simple GitHub template and those who prefer a configurable generator like cookiecutter.

I believe we can do this by using copier to manage the template source on a separate template branch. This allow for managing the template source on a separate template branch. The workflow would then be:

1. The template branch holds the copier.yml and all .jinja files. This is where all development happens.
2. The main branch holds the clean, rendered output. It remains a valid GitHub template with no .jinja files.

A GitHub Action would automatically render the template branch to main on every push.

This approach makes it easier to add and maintain advanced options, like documentation, runner actions, etc. The main benefit over cookiecutter is that users can later pull in template updates with copier update, which would otherwise need cruft on top to achieve the same.

Users wanting the simple GitHub template see absolutely no change. Those wanting the configurable version would just point to the template branch like this:

uvx copier copy -r template gh:carderne/postmodern-python <your-project-name>

side-note: this also shows why uv is amazing to just run random commands in a temporary environment.

This could give us the best of both worlds. What do you think?

---

the example repo with the templates can be found here: https://github.com/jakob1379/postmodern-python-copier
that is able to exactly generate the current main, but is still missing the github-action that ties it all together.

[carderne]

Hey @jakob1379 sorry for the slow response. This sounds pretty good, want to give it a shot with a PR? CI script should be pretty simple (sure an LLM can sort it out if needed).

[jakob1379]

no need to be sorry, I have work and life to do, so no rush. I will give it a shot.

[jakob1379]

I have something that works, but since I can't make branches in your repo, I cannot start a PR before a branch has been made. My solution is here and has been rendering the current main branch:

https://github.com/jakob1379/postmodern-python/tree/template

The github action produces the current main with the only differences being:

1. an updated python version 3.13 from 3.13.1.
2. a file called .copier-answers.yml on the main which we can ommit. This allows copier to use its update functionality, but strictly not relevant for your main branch, so unless you want to save it, I think we should exclude it

[carderne]

Hey @jakob1379 I just invited you to the repo. Please go for it, and agreed on that extra file.

[jakob1379]

closed with #5