Closed Bueddl closed 1 year ago
Just to highlight how this would be used, consider this example:
{
"default_attributes": {
"choco_packages": [
{
"name": "postgresql",
"params": "/Password:postgres",
"version": "10.18.2",
"options": ["--x86", "--params-global"]
}
],
...
}
You are changing the existing way of configuring choco_packages in a backwards incompatible way. We shouldn't break existing configurations while fixing a bug. So the code should accept either a single string or an Array of strings as options and construct the commandline accordingly.
You are changing the existing way of configuring choco_packages in a backwards incompatible way. We shouldn't break existing configurations while fixing a bug. So the code should accept either a single string or an Array of strings as options and construct the commandline accordingly.
Yes I was worried about that too. I will add changes to make it backwards compatible.
@damphyr I added a tokenization step in case the options were provided as a string.
This change is related to PR #49 and exists for the same reason. Since chef passes the parameters to choco as an array the options can no longer be a plain string. This becomes apparent when using options together with params or when using more than one option since the entire string of options is then passed as one option to choco.
For example when specifying options "--x86 --ia test" and params the exec args become:
instead of:
Note that here are actually 2 issues that are caused by this:
I suggest switching to an array for the options which works fine and fixes both issues. However existing cookbooks that use options would have to be changed to use arrays instead of strings for specifying options.