construct list of choices via a for loop

[dudicoco]

Hi,

I'm trying to construct the choices list via a jinja for loop:

project_type:
  type: str
  choices: ['{% for i in ["one", "two"] %}{{ i }},{% endfor %}']

However, this results in a single quoted item in the list:

project_type
(Use arrow keys)
>> one, two

How can the choice be split into a proper list?

[pawamoy]

I'm afraid it is not possible to use Jinja in such a way in copier.yml. If the file itself was templated, you could do this:

project_type:
  type: str
  choices: [{% for i in ["one", "two"] %}'{{ i }}',{% endfor %}]

...but that is not the case: only values are templated. Therefore you cannot use Jinja syntax outside of quoted values.

I'm not sure whether there's a workaround 😕

[pawamoy]

Thanks for trying!

[sisp]

How about extending Copier to support Jinja native types using a custom YAML tag like this?

project_type:
  type: str
  choices: !!jinja2-native "[{% for i in ['one', 'two'] %}{{ i }}{% if not loop.last %},{% endif %}{% endfor %}]"

The !!jinja2-native (tag name open for discussion) YAML tag could inform Copier to use a Jinja NativeEnvironment instance instead of the regular environment.

It seems to me that native types could only be useful in copier.yml (like here for constructing dynamic choices), all other uses of template syntax seem to be in text files or file/folder names, so rendering as strings is fine there (but correct me if I'm wrong).

[pawamoy]

Or even a native template: https://jinja.palletsprojects.com/en/3.0.x/nativetypes/#jinja2.nativetypes.NativeTemplate. It seems possible to instantiate a NativeTemplate from a regular one: NativeTemplate(source=env.from_string(value)).render().

[sisp]

Without the custom tag? If so, it wouldn't be possible to render something as a string that would be parsed as a native type by a native template.

[pawamoy]

Indeed it still requires the custom tag 🙂

[yajo]

Why do you want to construct dynamic choices?

[pawamoy]

Another example I can give you: run an aws cli command to get the list of regions and pass those to the list of choices.

Thanks, that's a good example.

Another one: please select one of these existing, local Postgre databases, or new to create a new one.

[yajo]

Obviously, we could argue about the usefulness/robustness of such a question, but that's not the point here.

I think we should avoid feature creep, so I think this really is the point.

Dynamic choices have potential to affect negatively the update experience. How to reliably replay if the questionary isn't reproducible?

If I needed a use case like those, I'd use a text question and provide the question help: "visit this list link to see the aws regions and write here the one you want"; "run this command and write here its output"; etc.

You can also have a simple way to update your template questionary. One example here where I just tell my future self how to update that selection. Just run a command, copy, paste, done. I could do that manually once a year, or have a CI do it every night. In any case, that keeps replayability, so updates are guaranteed to be smooth.

The native templates seem a good approach, but this is one feature that could harm the experience so we should be sure it's worth it IMHO.

[sisp]

The effect on updating and replay is an important point! I think it's related to #1170 though: If there was no replay because a fresh copy using the old template is stored somewhere, it should be fine to have dynamically constructed choices, shouldn't it?

[yajo]

Of course.

[pawamoy]

I think we should avoid feature creep, so I think this really is the point.

I meant the exact question I used as an example (python interpreters). You are absolutely right about questioning the feature itself 🙂

[sisp]

Related to this question is the dynamic construction of a default value (a list of choice values) for a multiple-choice question.

[sisp]

How about allowing a string value for choices which gets rendered, parsed as YAML, and validated? This way, we could achieve dynamic choice items without the need for a generic solution. I think it should be fairly straightforward to implement it.

[yajo]

Seems a good idea

[sisp]

I've submitted a PR that adds support for dynamic choices: #1804