Using --data with a multiselect based choice

[chrisdaish]

Describe the problem

Follow on from: https://github.com/orgs/copier-org/discussions/1473

Template

fruit:
    type: str
    help: "Fruit?"
    choices:
        - apple
        - pear
        - banana
    multiselect: true

To Reproduce

$ copier copy --data 'fruit=apple' ../copier-issue .
...
ValueError: Invalid choice

Logs

No response

Expected behavior

Primary:
--data is able to find the 'apple' from the 'fruit' multiselect based choice, and select it.

Secondary:
To support multiple options perhaps multiple --data entries are required akin to:

--data 'fruit=apple' --data 'fruit=banana'

or comma separated

--data 'fruit=apple, banana'

or an array?

--data 'fruit=[apple, banana]'

Screenshots/screencasts/logs

No response

Operating system

macOS

Operating system distribution and version

Sonoma 14.2.1

Copier version

copier 9.1.0

Python version

Python 3.9.6

Installation method

pip+pypi

Additional context

No response

[noirbizarre]

My 2 cts (as the author of the multiselect feature):

Given https://github.com/copier-org/copier/blob/master/copier/cli.py#L162-L178 is already a list, and current behavior is "last value overrides previous", I would avoid the multiple flags approach as it would mean different behavior and different parsing strategies.

Between --data 'fruit=apple,banana' and --data 'fruit=[apple, banana]', I would chose the first one based on this:

• I think comma separated list are more common as parameter and potentially simpler to parse
• this is very personal, but I don't like CLI expecting JSON-like data: most of the time it's a lot of noise for nothing (accepting JSON but expecting only a subset which most of the time is easier to write in basic cli style), and often double escaping required
• if it's not JSON, it means it needs a custom parser and so more complexity and maintenance than splitting on commas

[sisp]

I think comma-separated values won't work in general, e.g. type: yaml or type: json might contain commas which should not be used to split multiple answer values for a multiselect question. 🤔

[yajo]

Have you actually tried the array way? Something like:

copier copy --data 'fruit=[apple]' ../copier-issue .

[sisp]

@yajo I've tried several ways, also with an array, none works. The problem is that the answer passed via CLI is a string, which gets parsed by

copier/copier/main.py

Line 438 in f92c1fe

answer = question.parse_answer(result.init[var_name])

which for multiselect questions does not work as expected because a list is expected:

copier/copier/user_data.py

Lines 439 to 440 in f92c1fe

	if self.multiselect:
	return [self._parse_answer(a) for a in answer]

I'm not sure what the best solution to this problem is though. Should we support string answers for all questions, which get parsed according to the question type?

[yajo]

I think the we just need a specific parser for multiselect questions. It could be a yaml that asserts the value becomes a list and casts its elements to the type of the question.

[lhupfeldt]

I just stumbled into this error. I also tried all the combinations of passing date mentioned above before deciding to open an issue, an then found this existing one 🥲
Is there really a need for allowing , in (multiselect) choice values?
I would like to vote for the simple comma separated format. If needed '\,' could be used on the commandline to allow ,.
Not being able to specify all data on the commandline is a real showstopper for automation.

[johannesloibl]

I have the same problem. I would prefer any solution, may it be comma-separated or JSON.
Until then it is: modify .copier-answers.yml, commit and update :(

[chrisdaish]

@johannesloibl rather than editing the .coper-answers.yml file directly - we have had more success by using the --data-file argument (--data-file fruit.yml for example) that we then author before hand (programatically) to include the following:

---
fruit:
- apple
- banana