Non-prompted values

In my templates I often duplicate code to build a string based on the user’s answers. I would like to avoid duplicating this code and instead populate a variable once, in copier.yml using a non-prompted value. The user must not change this value, I’d like to always use the default. Something like this maybe?

gitlab_namespace:
  type: str

repository_name:
  type: str

# here
namespace_id:
  type: str
  prompt: no
  default: "[% if gitlab_namespace.count('/') %]r-[% else %]p-[% endif %][[ gitlab_namespace.split('/')[-1] ]]"

# then I could populate other variables as well, these are just examples
docker_image:
  type: str
  prompt: no
  default: "[[ namespace_id ]]/[[ repository_name ]]-docker"

package_distribution_name:
  type: str
  prompt: no
  default: "[[ namespace_id ]]-[[ repository_name ]]"

There surely are other ways than introducing a new prompt key to do this though, like injecting data in the context from a special _context list or a pre-generation hook (like a Python script modifying and returning the context dict). Maybe there’s a way to play with Jinja2’s extends, include, macro, with or set capabilities as well 🙂

[pawamoy]

I forgot to report back. It actually works. Filename are horribly long and difficult to read, but it works. The “context” file also must be placed at the root of the template, because slashes are not allowed in filenames.

[yajo]

Those problems are not big deals IMHO. I am used to importing other functions from other modules in Python and that sounds natural to me. Actually, being explicit on why things work is good, thinking about maintenance (not just Copier, but also downstream templates).

About parenthesis, actually they seem good to me also. If you’re all the time reusing the same macros (slugify could be one of those), you can have a separate git repository with macros that you include as a submodule in your other templates (remember Copier supports git submodules). Then, it would make more sense to use macro arguments, since the context can easily differ on each template. Maintainability isn’t always about saving keystrokes! 😊

Well, as I think we agree this is a good solution, let me close this. Thanks!