Add support for source git-repos where the template is located in a subdirectory

[nickgarber]

Actual Situation

We use a monorepo branching strategy where the root directory is shared and kept in common among multiple branches.

In this strategy, there is only one solution per branch and it's added into a distinct subdirectory.

Desired Situation

I'd like to maintain Copier templates, one per branch, but can't seem to identify a way to indicate the subdirectory that each template should be found in. If this isn't already possible, could it be added?

Many thanks for the project!

Proposed solution

It brings to mind the ?dir=<subdir-path> git-url suffix used by Kustomize to specify a file or directory path within a git repo.

Something like that would be a nice addition to the project and elegantly remove this seemingly arbitrary template-placement restriction.

[sisp]

This is answered in the docs: https://copier.readthedocs.io/en/latest/configuring/#subdirectory

Can I have multiple templates in a single repo using this option?

The Copier recommendation is: 1 template = 1 Git repository.

[...]

Looks like a duplicate of #315 #1078 #1279. See especially #315 (comment).

I'm closing this issue, but feel free to continue the discussion.

[nickgarber]

Hiya @sisp I want to clarify my use-case is basically 1 Template = 1 Git repo

Our branching strategy just discourages making changes to the root directory, so I'd like to add the template to a sub-directory.

[sisp]

@nickgarber And having only copier.yml in the root directory is no option? The template content can be located in any subdirectory using the _subdirectory setting.

[nickgarber]

Right, I think I'll eat the frog and pursue that approach. Thanks for your guidance!

[yajo]

Hi there! Thanks for this proposal. The feature has been asked many times as you can see. However, none of the solutions had in mind important features such as updating and migrations. The main problem was that git tags are repo-global, so by using branches copier would lose those features.

The monorepo approach you suggest is the 1st proposal that could actually work. By changing the src url directly, we get a canonical path where to search for updates. Since all can be done still in the same branch, we can still rely on tags.

Problems still present with that approach:

• it's still not so simple
• you could get updates where nothing changes.
  • FWIW this could still happen depending on your answers on any normal project.

Benefits:

• You could have different copier.yml files, each one with different settings
• We could support an alternative repo layout, giving our users more freedom of choice without compromising other features.

Due to my limited time availability lately, I will be honest: I will not develop this. However, if @copier-org/maintainers agree, we can reopen and leave it as proposed for community contribution.

Although it probably requires more gymnastics depending on your case, you can already get it with the workaround suggested. So, do you still think it's worth it @nickgarber? Would you be willing to push a PR?

[nickgarber]

Appreciate it! I've taken some time to consider and would be interested to create a draft implementation.

I think monorepo users the world over would thank us.

Is there still a warm feeling towards reviewing a proposal in support of per source branch encoded templates?
If so, is something in line with how nix flakes handles this seen as a suitable approach?

• ref: https://nix.dev/manual/nix/2.18/command-ref/new-cli/nix3-flake#url-like-syntax

[yajo]

No, copier considers a repo a template.

This is because copier uses tags to compute migrations, and tags are repo-wide, not branch-specific. Thus, we can't rely on branches for the auto-updating.

Yes, you can use branches, as long as you always specify -r branch_name when running copier.