(GH-83) Turn off download progress

[jrdnr]

Fixes Issue #83 "Turn off download progress"
Choco Versions >10.4 overwhelm log with download Progress data

Added Check for Choco version and add "--no-progress" to the Params list

• Renamed Params variable for consistency across functions
• Updated Choco comand execution formatting to be consistent across functions

[ferventcoder]

Pretty good, but finding the version of Chocolatey is quite a bit simpler, plus there may be times where (depending on how it was installed) there may not be a Chocolatey nupkg in the lib folder.

[jrdnr]

The reason I used Get-ChocoInstalledPackage instead of choco -v, is because of the work done with caching the package list, running choco -v 15 times takes about 10.3 seconds, where as running Get-ChocoInstalledPackage takes about 1.6. Pushing that up to 45 repetitions and choco -v is around 30 seconds and Get-ChocoInstalledPackage is still only at 1.8 seconds.

I'm sorry I don't know enough about how Choco works to follow what would happen if there were not a "Chocolatey nupkg in the lib folder" would this mean that choco list -lo -r would not return a value for chocolatey?

[ferventcoder]

I'm sorry I don't know enough about how Choco works to follow what would happen if there were not a "Chocolatey nupkg in the lib folder" would this mean that choco list -lo -r would not return a value for chocolatey?

It depends on how Chocolatey was installed, but folks are free to install it in their own ways and while we wish everything was a good steward about getting the nupkg in the proper place, that isn't always true. Above that, for the longest time even our scripts were not doing it correctly, so some of the configuration managers out there were also implementing it wrong. So we can't assume that the nupkg is there.

The reason I used Get-ChocoInstalledPackage instead of choco -v, is because of the work done with caching the package list, running choco -v 15 times takes about 10.3 seconds, where as running Get-ChocoInstalledPackage takes about 1.6. Pushing that up to 45 repetitions and choco -v is around 30 seconds and Get-ChocoInstalledPackage is still only at 1.8 seconds.

This is a great point. Perhaps cache the version output as well? I think it will be even faster than iterating the cache of installed packages and it will also be more accurate due to the above constraints.

Thoughts?

[jrdnr]

I would agree, there would be time savings from caching choco -v especially since it wouldn't need to be purged or expired as frequently as Installed Package. The question I wasn't quite sure how to deal with is logic around how to decide if the cached version is still valid, I'm tempted to go with a blunt solution like a 60 second timer, worst case scenario Chocolatey gets updated during a DSC run and any remaining work is done without --no-progress. Is there a reasonable way to know if choco gets upgraded or should I just go with the timer?

[ferventcoder]

Is there a reasonable way to know if choco gets upgraded or should I just go with the timer?

I think the timer is going to be fine.

[jrdnr]

@ferventcoder Let me know if there are any other items that need to be addressed before this can be merged. If this is good to go as implemented I can squash it down and correct the commit messages that are inaccurate.

[pauby]

@ferventcoder Can you take a look at this and see if there is anything else needed since your review?

[jrdnr]

Thanks for the bump @pauby would love to get this into into production, would do a lot to clean up logs.
cc. @ferventcoder

[pauby]

@jrdnr I've gone through and resolved the conversations by @ferventcoder - just one small point from me, where we can use Advanced Functions. After that I'm happy to give this a spin and merge.