Is this a valid use for when: false?

[pfmoore]

The documentation says about when conditions for questions, that "If it is a boolean, it is used directly, but it's a bit absurd in that case". But I've found what I think is a reasonable use for this, and I want to check if it makes sense (or if there's a less hacky way of doing what I want to).

My problem is that I want to calculate some values based on the answers already given, and name the result. My use case is that I want to generate a file based on some messy conditions, and a file name of the form {% if condition1 and answer == 'foo' %}somefile.txt{% endif %}.jinja looks very ugly, and is hard to work with. So what I'd like to do is set a "variable" to {% if condition1 and answer == 'foo' %}somefile.txt{% endif %}, and then the file can be {{variable}}.jinja.

This is possible in the copier.yml file by doing:

condition1:
    help: Does condition 1 apply?
    type: bool
answer:
    help: What is the answer?
    type: str
    choices:
        Option 1: foo
        Option 2: bar
variable:
    when: false
    default: "{% if condition1 and answer == 'foo' %}somefile.txt{% endif %}"

Is this a good idea? If so, would it be a useful addition to the documentation (maybe as a FAQ entry)? Or is there a better way of doing this that I haven't spotted?

[wsascha]

I guess another option would be to modify the context which hides away some internals from the questions file.

[pfmoore]

Agreed, although that means that the user has to have the extension installed.

[yajo]

As the docs say:

copier/docs/configuring.md

Lines 144 to 147 in c16b0b8

	If a question is skipped, its answer will be:
	- The default value, if you're generating the project for the 1st time.
	- The last answer recorded, if you're updating the project.

But if we use when to have computed values, then we'd have to process the answer always, no matter if it has changed in a previous update.

It could be a behaviour, but it could lead to surprises, like: why did Copier update this question if I didn't answer it? And I like to keep it predictable whenever possible.

This has been discussed before. You can see the whole story in #629. It contains some ideas that can serve you.

In short, since there's an extension that handles that case, I'm deliberately not supporting it upstream, to keep Copier on scope.

[pfmoore]

OK, that makes sense to me. And the point about updates is exactly the sort of subtle problem that I'd missed, which makes using when: false a bad idea.