Can't inspect installed choco packages without an ohai plugin

[erlogan]

Describe the Enhancement:

I would like to be able to see the state of packages currently installed a Windows system by chocolatey without having to rely on anything external, like an ohai plugin.

Describe the Need:

I have some cross-platform library code that inspects the current state of installed packages that I am extending to work on Windows. On a platform that uses yum or dnf, I can use their python_helper library to inspect the current list of installed packages. As the code is today, the chocolatey provider lacks anything similar: it has an installed_packages method, but it is private and, as an instance method, isn't suitable for use in outside libraries even if just flipped to public.

Current Alternative

When the chocolatey ohai plugin is installed, this information is available in node['chocolatey'], but this has two drawbacks:

1. Requires the chocolatey ohai plugin to be available and installed (which it might not be), whereas the chocolatey package provider is always available
2. The state of packages may have changed since ohai gathered data, which would force me to write a block to reload ohai

Can We Help You Implement This?:

I have a change that converts the chocolatey package provider's installed_packages method from a private instance method to a public class method, and as the PR template requests, I'm filing this issue in preparation for a PR.

[lamont-granquist]

This needs to not be done as a chocolatey one-off. We need a consistent API for accessing installed and candidate versions of packages across all the different package providers. The helpers need to go into chef-utils and they need to work across all the major package providers (apt/yum/zypper/rpm/deb/homebrew/gem/chocolatey)

[tas50]

This data also needs to get exposed in Ohai so that we can send it to reporting. It's not something we currently collect and that's a gap.

[lamont-granquist]

And people need to stop poking at the python_helper libraries, those shouldn't even be a public API really and their use needs to go away and be replaced. The whole python helper should be an implementation detail.

The new API should be something like def installed_package(package_name, resource_name = :package) to get the current package along with candidate_package and probably def installed_package?(package_name, constraint, resource_name = :package) and similarly candidate_package? for asking if the installed or candidate satisfies a constraint. But that's just off the top of my head.

And yeah, we should update ohai as well, but that's the wrong API to use due to the need to reload the plugin after every package update to get accurate info.