Remember git branch in updates

[ruestefa]

Goal

I am experimenting with how to best handle templates that differ only in a few aspects, e.g., a for a pure-Python project and one with f2py support. A single git repo with multiple main branches, one for each flavor of the template (e.g., main, main-f2py), seem like a good way to handle this.

Problem

In principle, this works well by specifying the branch with --vcs-ref. Unfortunately, there does not seem to be a way for copier to remember the branch during copier updates, i.e., users always need to pass the correct --vcs-ref flag, which is not feasible.

(Right now, the only way I see to manage multiple related templates in one repo while not burdening users with --vcs-ref during updates is to create a fork for each flavor of the template, which seems unwieldy, especially if the template is hosted on multiple platforms.)

Possible solutions

• Add an option to remember --vcs-ref in .copier-answers.yml and, if present, reuse that value during updates.
• Add support for branches to the URL syntax, e.g., with a @<branch> suffix as suggested in Template in a different git branch  #227.

What else I've tried

Copier support multiple templates for a project, e.g., a pure-Python base template with a partial template with f2py modifications. This works but requires exposing the user to multiple templates. To avoid that, I've experimented with "meta templates", i.e., templates with two tmpl/ layers, that can be combined into complete templates. This does work, but complicates maintenance and feels more like a hacky workaround than a proper solution.

[yajo]

Hello and welcome! Copier is indeed a bit opinionated about how are you supposed to develop your templates. The canonical way is: a main branch, PEP-440 tags for releases, and branches are useful for testing volatile changes until merged in the main branch. Why is that so? Because of updates. For them to work, we need to be able to reproduce last render, new one, and compare both with current state of the project. For future-proof updates, you need migrations. For migrations, you need tags. And tags are global for git, not per branch. So, if we use moving refs (like branches), we lose all of that. To give your desired use case appropriate support, we'd need to cut down so many features that it would be more practical for you to use other tools that don't care so much about uplates and so don't worry about these things. But we want you here, so what could you do to solve your need? Option 1: use 2 repos instead of 2 branches. If you fork one from the other, you'll be able to share commits back and forth with not much more effort. Option 2 (more canonical): single repo, single branch. You just add a question to your questionary: ```yaml # copier.yaml f2py: default: false ``` Then use that variable in your templates to add support for f2py conditionally. I think option 2 is better because it will remember the answer for updates and you'll have the full potential of copier because you will follow its mental model. But it's up to you. As you can see, it's almost impossible to support your proposal, so I'll close this one. Let me convert it to discussion, as this will be more helpful there. Thanks! El mié., 21 dic. 2022 10:48, Stefan Rüdisühli ***@***.***> escribió:

…

Goal I am experimenting with how to best handle templates that differ only in a few aspects, e.g., a for a pure-Python project and one with f2py support. A single git repo with multiple main branches, one for each flavor of the template (e.g., main, main-f2py), seem like a good way to handle this. Problem In principle, this works well by specifying the branch with --vcs-ref. Unfortunately, there does not seem to be a way for copier to remember the branch during copier updates, i.e., users always need to pass the correct --vcs-ref flag, which is not feasible. Possible solutions - Add an option to remember --vcs-ref in .copier-answers.yml and, if present, reuse that value during updates. - Add support for branches to the URL syntax, e.g., with a @<branch> suffix as suggested in #227 <#227>. Right now, the only way I see to manage multiple related templates in one repo while not burdening users with --vcs-ref during updates is to create a fork for each flavor of the template, which seems unwieldy, especially if the template is hosted on multiple platforms. *What else I've tried* *I am aware of the solution copier provides for templates that only differ in a few aspects, which is to use multiple templates for a project, e.g., a base template for complete pure-Python projects along with a partial template that only contains the changes required for f2py support. This indeed works fairly well, but it requires exposing the user to multiple templates.* *To take advantage of partial templates while still exposing the user to only a single complete one, I've experimented "meta templates", i.e., templates for templates with two tmpl/ layers that are used as parents for the final templates. This does work, but makes maintenance a bit complicated, and it feels to much like a workaround than a proper solution.* — Reply to this email directly, view it on GitHub <#900>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHNXDNB2R2SSRH2JUKIJUTWOLOALANCNFSM6AAAAAATFPOEZI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ruestefa]

Hi, thank you for your quick and detailed response! I see your point, so it indeed probably doesn't make sense to go down my proposed road.

I've meanwhile found a workable solution in creating a separate empty repo (not a fork) per template flavor and only push the respective branch there. This approach only requires one additional push per branch to propagate changes while all the work can still be done in a centralized repo.

As for your one-repo-one-branch proposal with conditional content: We used conditionals for some things in an earlier version of the template, but this tends to litter the files (and file names) with jinja2 directives. I find keeping track of the differences in git branches with standard git tools much simpler and more transparent.

it would be more practical for you to use other tools that don't care so much about uplates...

Updates were the single reason I switched from cookiecutter to copier in the first place (and they work well), so I won't give up on that. :-)

Thanks for your work and prompt support!