Replies: 1 comment 3 replies
-
You know what? This makes total sense. Regarding your question about why this is done like it is... well, nobody thought about this other option, honestly. 😆 My guess is that we could get this to be totally backwards-compatible by splitting the answers in yaml sections instead: _commit: 0c4105a
_src_path: ./template_aaa/
project_name: drewtonian
---
_commit: f566260
_src_path: ./template_bbb/
output_path: ./output/ We could use the src path to select the template. WDYT? cc @copier-org/maintainers |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
My apologies if this topic has already been discussed, but I wasn't able to stumble across it in my initial search. But I was curious if there was a strong reason why the .copier-answers.yml file doesn't exist as a digest of answers for all the applied templates?
I understand that the current paradigm is to have a single answers.yml file for each template that has been applied to a project. When it comes to updating a project with a new version of a template, the burden is then on the user to know which answer file to pass to the
-a
flag incopier update -a <answer-file>
.So the question is, is it conceivable that copier could support multiple template answers in a single
.copier-answers.yml
file. For instance:Ideally the end user would be able to run
copier update
and expect that updates from both templates would be applied. Or alternatively, they could runcopier update --template template_b
and expect that just updates for template_b would be applied.And of course, I'm sure there are many subtleties that I'm overlooking, but this seems much more intuitive for the end user of a rendered project. The obvious downside is the potential for name collisions, but that seems like a problem that could be addressed.
Beta Was this translation helpful? Give feedback.
All reactions