Disallow str-parseable input by API #280
Comments
yajo
pushed a commit
that referenced
this issue
Oct 19, 2020
If calling Copier through CLI, it's normal to convert all strings to expected data, but if calling through API, you should know what kind of data you're passing in, so it shouldn't try to be smarter than you. Fix #280.
|
After developing the "fix" in #295 I just realized that it's better how Copier handles this now. It makes the same data conversions if data comes from CLI, from API, from copier-answers or from user answers. That's the most expected use IMHO, so closing. |
|
Still reconsidering this... 🤔 |
yajo
added a commit
that referenced
this issue
Jan 31, 2021
- Removal of Questionary class, which only had 1 meaningful method that is now merged into Worker to avoid circular dependencies. - Fix #280 in a simple way: only user answers are type-casted inside API, and CLI transforms all `--data` using YAML always. Predictable. - Use prereleases correctly. - Reorder AnswersMap to have a more significative repr. - Simpler cache for old `Question.get_choices()` method (renamed now).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Copier allows API input such as
"true"for a bool question, and converts that toTrue. And the same for all data types.The reasoning behind this is that CLI always sends strings.
But this overcomplicates the implementation and makes CLI arguments more surprising, as they can get casted to different answers depending on the question type.
Gotta remove that nonsense. Instead, make the CLI app transform all data before sending it to the API. And use always the same transform method: YAML.
The text was updated successfully, but these errors were encountered: