Upgrade of package when State is Present and Version is specified, fails unless forced

[steviecoaster]

Offending code:

if (-not $package_versions.Contains($version) -and -not $allow_multiple) {
                    $module.FailJson("Chocolatey package '$package' is already installed with version(s) '$($package_versions -join "', '")' but was expecting '$version'. Either change the expected version, set state=latest, set allow_multiple=yes, or set force=yes to continue")
} elseif ($version -notin $package_versions -and $allow_multiple) {
     # add the package back into the list of missing packages if installing multiple
     $missing_packages.Add($package) > $null
}

WORKAROUND:

- name: install Notepad++ at 7.6.3
  win_chocolatey:
    name: notepadplusplus
    version: 7.6.3
    allow_prerelease: yes
    state: latest

[vexx32]

This seems to be by design, at least going from the error message the code gives back here.

Though at least from my perspective it seems a little odd to require a different state for upgrades vs fresh installs, when choco is usually perfectly able to upgrade packages...

Maybe because this module also supports --allow-multiple and it could get confusing whether the user is asking us to upgrade a package vs install a side by side? 🤔

@jborean93 might be able to speak to the design intent here.

[jborean93]

The code around this snippet provides a bit more context https://github.com/chocolatey/chocolatey-ansible/blob/master/chocolatey/plugins/modules/win_chocolatey.ps1#L780-L794.

This is only run when state: present and an explicit version is set. If the version reported by Chocolatey does not match what is installed and allow_multiple: yes is not set then it considers it a failure. Essentially the module currently treats state: present as install but never update so if you specify a version that isn't installed then it considers it a failure.

Maybe this could be amended by having the module implicitly upgrade it but how do decide what to update if there are multiple versions and allow_multiple is not set.

Oh did I mention package management versioning is hard :)

[vexx32]

how do decide what to update if there are multiple versions and allow_multiple is not set.

I don't think Chocolatey itself handles this eventuality well either, really, even if you did have --allow-multiple on the command, I doubt I'd be able to predict what Chocolatey would do in that kind of situation. It's probably part of the reason Rob tends to recommend against using side-by-side installations.

I'm not sure there's a ton we can do to do better here, but maybe it'd be more intuitive for some folks if we simply added state: upgrade as an accepted value that internally follows the same logic as state: latest.

[steviecoaster]

Agreeing with @vexx32 here. --allow-multiple is a bit of an anti-pattern, and something we don't recommend. There's edge cases where it's needed (Java a good example), but by and large should be avoided.

I think state: upgrade is a good path forward.

[vexx32]

Tangentially related: chocolatey/choco#1022

If that issue goes somewhere in future we might end up with --allow-multiple being eclipsed/deprecated by that functionality, and we can more easily reason about what should happen from this module as well.

[drdamour]

I'm not sure there's a ton we can do to do better here, but maybe it'd be more intuitive for some folks if we simply added state: upgrade as an accepted value that internally follows the same logic as state: latest.

this and the docs confuse me, the way it reads it sounds like the behaviour is exactly the same as latest, but latests ignores the version correct? is upgrade constrained to the version?

[vexx32]

Neither latest or upgrade ignore a specified version. If you've specified a version number for either state, they will use just that version.

That confusion is somewhat exactly why I dislike the name latest for that state and why I added upgrade as an alias for it. But without breaking folks we can't remove latest at present, so until we do a major version release we'll have (somewhat confusingly) both states around.

[jansohn]

I think it is quite unintuitive that the combination state: present and version: '1.1' leads to an error if version 1.0 is currently installed. Wouldn't it be possible to let this combination just upgrade the package to 1.1?

[vexx32]

Sure, it's possible. It would be a fairly significant breaking change in the module behaviour, though, and I don't really see the value in changing it to effectively do the same thing as another state value. state: upgrade does the action you want already, so I think it's ultimately fine to have present as its own thing that lets users get an error back indicating that a node has the wrong version installed if that's something they care about.