Integrate copier-templates-extension into Copier

[pawamoy]

As suggested in #1633, it could be interesting to integrate the functionality of copier-templates-extension (at least the extension that allows loading other extensions from the template root, without having to package them) directly into Copier.

I initially developed it out of Copier to experiment (see #376). It was deemed too unsafe for integration within Copier. Since then, Copier has implemented the --trust flag which allows disabling the use of extensions, tasks and migrations (since these latter two are also unsafe), so maybe it's time to reconsider?

Modifying the context after the user provided answers, and adding filters like slugify are considered by some (many?) users very basic / non-brainers features that should definitely be part of the project, without having to install anything extra, as this extra install almost always means having to run a second command (therefore no one-liners possible with pipx run, rye tool run, uv tool run, etc.). I agree with these users, as without surprise I'm a user of copier-templates-extension myself.

If the main argument against integration within Copier is maintenance, well I'll counter-argue that I'm already maintaining the project 😅 If I start maintaining it in Copier, that changes a bit the process, but not the maintenance amount.

Another possible argument against integration is that it would tie the project to Copier's own release cycle, which could slow down Copier or copier-templates-extensions releases. However copier-templates-extensions has needed almost zero maintenance or new releases since it started to exist, so it might not cause any real issue.

Anyway, just starting this discussion in case others would like to share their opinion! No strong preference from me. I just think integration could improve Copier's UX/DX, but it's not critical.

[yajo]

I have to admit that my reluctance to integrate is is, simply put, that I never needed it. Also, that it'd be the 1st time we actually tie some feature to the Python language. Yes, Copier is always Python, but writing or consuming templates never needed it.

But I also have to admit your arguments are pretty good! 😊 So let's talk about it.

I understand the need for slugify, but it's as simple as adding this extension.

I understand the need for shortcuts, but nowadays we have computed fields in Copier.

I understand you might need some extra extension but... well, you can write an extension and include it in Copier.

Thus, what's the real use case that is really missing here? (Might be an obvious question, but remember I never used it 😅). Just to be able to evaluate the impact/benefit properly...

[sisp]

Wow, even monorepo support via workspaces. Okay, I know, getting off-topic, but that's really cool! Thanks for hinting at uv! I'll really take a deeper look.

[yajo]

Perfect!

[rassie]

I have the need to use context hooks in my environment, so I'll try to describe where I'm coming from.

I understand the need for slugify, but it's as simple as adding this extension.

The problem is, if I understand all intricacies correctly, you'd need jinja2-slug installed on every machine where copier is used. In my case it's a dozen different developers with diverse operating systems and, in most cases, little to no wish to do anything about installing Python packages. I'm trying to provide documentation with as few steps as possible. In terms of installing copier, the simplest installation routine for Mac and Linux users is just brew install copier, which makes installing extensions as unintuitive as it gets (/home/linuxbrew/.linuxbrew/Cellar/copier/9.4.1/libexec/bin/python -m pip install copier-templates-extensions in my case). I would very much like to have an escape hatch by vendoring extensions and context hooks in my template repository.

I understand you might need some extra extension but... well, you can write an extension and include it in Copier.

By "include it in Copier", do you mean "submit a PR"? The other interpretation would be "include it in your template", which is technically what copier-template-extensions are for, so I'm afraid you mean the former. It's not always viable to submit a PR, e.g. when an extension is quite specific to the use-case.

Thus, what's the real use case that is really missing here? (Might be an obvious question, but remember I never used it 😅). Just to be able to evaluate the impact/benefit properly...

More or less it the possibility to include auxillary Python code in the template repository, either as extension or a context hook, for any kind of specific or complex processing.

[yajo]

I see you point. However, I'm pretty sure that then the next request will be that the custom code in your template has a dependency... and we'll be back to the start. 🤷‍♂️

I don't want to become pip 2. 😅

you can write an extension and include it in Copier

FWIW I meant writing a Jinja extension and adding it as a requirement in your template.

you'd need jinja2-slug installed on every machine where copier is used.

Maybe you can consider writing a pure jinja implementation. Slugifying is a pure operation (no side effects), so it can be written as a macro.

Copier allows including git submodules and importing macros from them. Maybe someone could create a common library for sharing pure community macros?

[pawamoy]

@rassie just to reiterate on uv: it's a single exec, installable with curl, and with it your devs can simply run:

uvx --with copier-templates-extensions copier copy --trust gh:pawamoy/copier-uv project

If your extension has other Python dependencies, just --with them:

uvx --with copier-templates-extensions --with httpx copier copy --trust gh:pawamoy/copier-uv project

If you package your extension and publish it on PyPI (or other index), then it can declare its own dependencies, shortening the command to:

uvx --with your-extension copier copy --trust gh:pawamoy/copier-uv project

They don't even need Python installed: uv will install it for you.

I believe such one-liners are easy to document and easy to copy/paste in a terminal.