Is there a way to define variables in copier.yml?

[eyllanesc]

In my particular case I have the following copier.yml:

github_user:
  type: str

github_repo:
  type: str

And in various parts of my .jinja files I do the following:

"Changelog" = "https://github.com/{{ github_user }}/{{ github_repo }}/releases"

"Bug Tracker" = "https://github.com/{{ github_user }}/{{ github_repo }}/issues"

"Issues" = "https://github.com/{{ github_user }}/{{ github_repo }}/issues"

"Discussions" = "https://github.com/{{ github_user }}/{{ github_repo }}/discussions"

I want to define a variable in copier.yml that is the same as "questions":

{%- set repository = "https://github.com/" ~ github_user + "/" ~ github_repo -%}

And then use:

"Changelog" = "{{ repository }}/releases"

"Bug Tracker" = "{{ repository }}/issues"

"Issues" = "{{ repository }}/issues"

"Discussions" = "{{ repository }}/discussions"

Can this be done in copier?

[pawamoy]

You could use my extension, https://github.com/pawamoy/copier-templates-extensions, particularly the Context Hook extension, to augment your context (in this case adding the repository variable).

[pawamoy]

Yes, I think I like one of your suggestions: _globals: {}. Copier could read it, render each item, and inject them in the context, at the top-level (not under a _globals key). Could also be named _context or something similar.

[eyllanesc]

I loved that option but I see a drawback, for example why limit that variable to templates since it could also be used in the copier.yml itself, something like:

github_user:
  type: str

github_repo:
  type: str

_github_repository : "https://github.com/{{ github_user }}/{{ github_repo }}"

foo:
  type: str
  default: "foo {{ github_repository }}"

The option to create an attribute that indicates that the user is not asked also seems valid to me.

[pawamoy]

You make a good point. Repeating stuff in copier.yml is not fun either. Then I'm back to my initial request for a hidden-like boolean flag on questions 😅
Or maybe an option to directly say "don't prompt this, and use this value":

github_user:
  type: str

github_repo:
  type: str

github_repository:
  const: "https://github.com/{{ github_user }}/{{ github_repo }}"

foo:
  type: str
  default: "foo {{ github_repository }}"

[eyllanesc]

Exactly, that's the logic. But I am looking for options so that the change is not abrupt for the user, and does not break their configurations.

Readability is why I use Copier instead of Cookiecutter, and I just think the feature I'm proposing goes in that direction.

[Savlik]

Oh god, this would be so useful! It could be just another flag like when only with the difference to use default value instead of null. I think that all the functionality is there it just needs to be combined properly.

[yajo]

You can use a jinja macro.

Macros can be defined in one file and then imported in others. And allow you to reuse partial templates. It would fit your use case exactly AFAICS.

Example:

1. Definition: https://github.com/Tecnativa/doodba-copier-template/blob/6016a59fa9e109c96437bf849a09186ce1ac3fe9/_macros.jinja#L1-L4
2. Import: https://github.com/Tecnativa/doodba-copier-template/blob/6016a59fa9e109c96437bf849a09186ce1ac3fe9/devel.yaml.jinja#L1
3. Use: https://github.com/Tecnativa/doodba-copier-template/blob/6016a59fa9e109c96437bf849a09186ce1ac3fe9/devel.yaml.jinja#L21-L22

[eyllanesc]

@yajo The advantages of a global variable are different from those of macros:

• I don't want to implement a function but a variable, e.g., github_repository : "https://github.com/{{ github_user }}/{{ github_repo }}".
• I don't want to import the variable(or macro), my goal is to have a clean code so if I had N templates then with the macro I would have to import it in each one which is annoying.
• I want to reuse it in the copier.yml, whatever I point out here.

As I pointed out in previous comments, the feature I ask for would make the logic simpler, avoiding having repetitive code (or rather redundant). If Copier can define global variables like the answers to the questions then you wouldn't have to "import" anything and you could reuse it making your code less redundant and more readable.

My requirement does not break anything that is currently copied, on the contrary, it enriches the project and simplifies the task for users.

[yajo]

I understand your concerns, but this is something that is already doable just by using the underlying template engine, so I don't have a big motivation to maintain that.

In my experience, macros and imports are already a clean way to DRY. Give them a try. 😉

[eyllanesc]

I understand your point of view but precisely copier has a plus: it is not a simple template manager, it seems to me that it has greater potential and does not require so many changes to improve it, with the feature nothing that already works is broken, it just one more piece is added.

[yajo]

If you want to avoid importing the macro definitions, you can define that pattern in a file and include it instead.

[eyllanesc]

I understand that there are several workarounds for my request:

• Use macros.
• Use include.
• Use plugins.

But I see it more natural that this feature be implemented directly since I don't see any disadvantages, on the contrary, it improves the project. If I implement the functionality, would you accept the PR? For example, something that I liked to copy with respect to similar projects is that it is a clean and readable configuration and with the characteristic that I propose it would take a leap in that direction.

I also have other ideas to improve the project such as being able to select commits, tags or releases as can be done in cookiecutter but it seems that copier does not do it (at least from what I have checked it uses the latest release, tag or commit but does not allow selecting one of them) so I want to know how accessible you are regarding those improvements.

[yajo]

I appreciate a lot your suggestions and enthusiasm. However, regarding this particular feature request, I would not accept the PR because the use case is already covered. I'm sorry to say no, but sometimes it's needed to avoid becoming feature creep.

We have a big enough roadmap and little time. Regarding your other ideas, I hope you still want to open new threads about them so we can discuss them.

Thank you again 😊

[eyllanesc]

Sad but fair. What new goals do you have for Copier or will only what already exists be maintained?

[yajo]

Most immediate goals are:

1. Finish all issues from https://github.com/copier-org/copier/milestone/13
2. Publish beta and ask community to test.
3. Finish beta and release v6.
4. Promote it.
5. clear deprecated stuff
6. Some contribution flow enhancements.

I keep https://github.com/copier-org/copier/milestone/15 for future ideas.