Skip to content

copier-pdm¤

copier-pdm

I was first introduced to project templating with CookieCutter and especially the cookiecutter-pylibrary from @ionelmc. I learned many, many things about Python thanks to Ionel and his template, discovering its features, design choices, opinions, and selected tools during the years I worked with it. I eventually forked it into my own cookiecutter-pydjama, which was mostly designed to quickstart Django apps. Then I slowly stopped using Django, and therefore stopped maintaing my cookiecutter, which is now archived.

Back when I was still using cookiecutters, one of the main challenges was to keep generated projects up-to-date with the latest change in the upstream cookiecutters. I'm always working on a lot of Python projects in parallel, so without a way to keep each one of them tightly structured, they all drift apart and it's hell to maintain them and switch from one to another.

A solution to this, discussed on CookieCutter's issue tracker, was to set up a template branch on the generated repositories, branch that was dedicated to receiving templates updates. These updates were then merged into the main branch, so as to allow a bit of drifting from the template, but still stay up-to-date. It was implemented using a clever mix of git and bash commands. And it was not perfect.

Then cruft (by @timothycrosley) made its appearance. At that time I was not really using templates anymore, but was still lurking on cookiecutter#784 and cookiecutter#1004 to make sure I would not miss any great attempt at solving this problem.

Cruft is basically a wrapper around CookieCutter that brings this updating functionality using some git magic. Like a more robust and efficient version of my previous shell script. I used it for some time, discovered some issues, sent one or two PRs. But I was not really satisfied, and the project was not really active (it is now, thanks to @samj1912 who really improved it).

And then, Copier made its entrance. A modest entrance. But a very interesting one. In a few hours of checking it and testing it, I was hooked. I took my old cookiecutter and started translating it to a Copier template, opening issues with feedback in the process. And it worked so well! I used this opportunity to also update my tools stack, trying out new bleeding-edge cool things to build the best Python project template I could.

And this is how copier-poetry was born!

Wait what? copier-poetry? not -pdm?

Well yeah, before PDM, I was using Poetry (and am still using it). Poetry simply revolutionized Python packaging and dependency management. I'll let you see for yourself. At some point though I discovered PDM, and it promised such great things! The exceptional UX of Poetry, but more in touch with the new cool PEPs around pyproject.toml and packaging, like (and I quote):

  • PEP 582 local package installer and runner, no virtualenv involved at all.
  • PEP 621 project metadata format.

And it reads pip's configuration, which makes it so easier to integrate in corporate environments! And it has groups for development dependencies 😱

(It's funny because @sdispater and @frostming, authors of Poetry and PDM, seem to have worked together before!)

I couldn't resist and duplicated copier-poetry into copier-pdm. It's the same thing, but with PDM instead of Poetry. If you are using copier-poetry, I'm sorry, all my love will now go into copier-pdm and I likely won't update copier-poetry anymore 😕 But I'll review your PRs of course!

To go back to Copier: Copier is a templating system and CLI tool with the ability to generate projects from templates (using Jinja2) and the ability to update them, which is built-in, when the template evolves! Not being a wrapper around another tool allows it to have great features, such as migrations, tasks, self-templating, multi-templating, interactive prompts, and more! At the time of writing, @Yajo has put and is putting a lot of work into improving Copier, and I can't wait for v6!

Comments