The package_exists? method doesn't seem to work.

[docwhat]

Chef: 12.4.3
Cookbook: 0.4.1

The package_exists? method doesn't seem to work. I don't see the INFO message "blah already installed - nothing to do." and I always see the execute being run.

This is problematic because I have reboot handlers for certain packages and with the package_exists? being broken, it is causing a reboot every run.

[mwrock]

I just validated same chef and cookbook version works as expected on my vm. I'm simply running:

include_recipe 'chocolatey'

chocolatey 'Console2' do
    version '2.0.148.20140727'
end

Do you mind sharing your recipe?

Could you try running:

choco list -l -r <package name>

on your node and see if it returns anything? If you are pinning to a version, check that it matches.

[docwhat]

The choco command returns package and version but it isn't separated by |.

[ferventcoder]

What version of choco? If 0.9.9.9, you should upgrade immediately - we found this issue with it and released a fix in 0.9.9.10 within hours - chocolatey/choco#450

[ferventcoder]

In 0.9.9.11 we put in an additional fix for listing pins.

[docwhat]

0.9.9.5... So we need to manually upgrade chocolatey? The cookbook doesn't manage that for us?

I see an output like this:

 * chocolatey[chocolatey] action upgrade (up to date)

[docwhat]

I just upgraded to 0.9.9.11 and I now see the | character. BTW: When I used choco upgrade chocolatey it said it wasn't installed. But I don't see any harm in its update. Is that a side effect of the cookbook? Maybe because I've been using the cookbook since 0.8.x?

[docwhat]

Just for posterity the fix (at this time) is to run:

c:\> choco upgrade chocolatey -y

Then the cookbook will start detecting if things are already installed.

[ferventcoder]

0.9.9.5 should have been doing the right thing. It was less than 0.9.9.2 and 0.9.9.9 that were the known incompatible versions.

[ferventcoder]

Either way, good to know you were good to go.

[ferventcoder]

Chocolatey has long been known not to know that chocolatey itself is installed (so it doesn't know about upgrades). This was fixed recently on the website and now is also fixed in choco 0.9.9.9+.

[docwhat]

@ferventcoder Just a suggestion -- add explicit formatting outputs for choco, like --format json so that this won't be an issue in the future for scripts trying to control chocolatey.

[ferventcoder]

I believe such a ticket exists.

[ferventcoder]

@docwhat here it is chocolatey/choco#159

[ferventcoder]

add explicit formatting outputs for choco, like --format json so that this won't be an issue in the future for scripts trying to control chocolatey.

I'm not quite sure how changing the format is going to resolve the issue. I did a quick spike on outputting xml (because it's built in). This is only like five messages from choco list -lo -r:

<event logger="chocolatey.infrastructure.app.services.NugetService" timestamp="2015-11-04T13:59:37.7764193-06:00" level="INFO" thread="10" domain="choco.exe" username="rob">
  <message>xunit.assert|2.0.0</message>
  <properties>
    <data name="log4net:UserName" value="rob" />
    <data name="log4net:Identity" value="" />
    <data name="log4net:HostName" value="test"/>
  </properties>
</event>

<event logger="chocolatey.infrastructure.app.services.NugetService" timestamp="2015-11-04T13:59:37.7920227-06:00" level="INFO" thread="10" domain="choco.exe" username="rob">
  <message>xunit.core|2.0.0</message>
  <properties>
    <data name="log4net:UserName" value="rob" />
    <data name="log4net:Identity" value="" />
    <data name="log4net:HostName" value="test" />
  </properties>
</event>

<event logger="chocolatey.infrastructure.app.services.NugetService" timestamp="2015-11-04T13:59:37.7920227-06:00" level="INFO" thread="10" domain="choco.exe" username="rob">
  <message>xunit.extensibility.core|2.0.0</message>
  <properties>
    <data name="log4net:UserName" value="rob" />
    <data name="log4net:Identity" value="" />
    <data name="log4net:HostName" value="test" />
  </properties>
</event>

<event logger="chocolatey.infrastructure.app.services.NugetService" timestamp="2015-11-04T13:59:37.7920227-06:00" level="INFO" thread="10" domain="choco.exe" username="rob">
  <message>xunit.runner.console|2.0.0</message>
  <properties>
    <data name="log4net:UserName" value="rob" />
    <data name="log4net:Identity" value="" />
    <data name="log4net:HostName" value="test" />
  </properties>
</event>

<event logger="chocolatey" timestamp="2015-11-04T13:59:37.7920227-06:00" level="INFO" thread="10" domain="choco.exe" username="rob">
  <message>Exiting with 0</message>
  <properties>
    <data name="log4net:UserName" value="rob" />
    <data name="log4net:Identity" value="" />
    <data name="log4net:HostName" value="test" />
  </properties>
</event>

Other than simply changing the output to json or xml, it doesn't seem like it will solve the issue in a way that you might like to see, which is more about breaking down the data as it comes out. That is a lot more involved and is not something we are currently exploring.

[docwhat]

The idea I had is that unlike the normal output, designed for humans, the XML or JSON output would be pre parsed and easy for a script to consume.

It's the difference between Git's porcelain and CLI stuff.

The format for programs to consume won't break backwards compatibility, but the human interface can change as desired.

But I'm not a powershell person, so maybe objects solve this?

[ferventcoder]

But I'm not a powershell person, so maybe objects solve this?

@docwhat And that is where chocolatey.lib comes in.