Questions about Chocolatey CLI integration in UniGetUI

[gep13]

👋 Hello, my name is Gary, and I am one of the maintainers of the Chocolatey family of projects, and I had some questions about the integration of Chocolatey CLI in to UniGetUI. I thought that raising this as a discussion was the best way to go, but if there is somewhere else that you would like to discuss this, please let me know.

Why is there a version of Chocolatey CLI bundled into UniGetUI, rather than defaulting to using Chocolatey CLI, only if it is installed on the machine (and perhaps providing an ability to install Chocolatey CLI, if it is not detected).

The issue with bundling a version into UniGetUI is that it can become outdated, as new versions of Chocolatey CLI is released. This adds work to the maintenance of UniGetUI.

In addition, running choco list against the bundled version of Chocolatey CLI, will report different packages as being installed, compared to the machine level installation of Chocolatey CLI.

Was there something in how Chocolatey CLI works with UniGetUI that required there to be a bundled version?

[marticliment]

I thought that raising this as a discussion was the best way to go, but if there is somewhere else that you would like to discuss this, please let me know.

Yeah, this is fine 🙂

Why is there a version of Chocolatey CLI bundled into UniGetUI, rather than defaulting to using Chocolatey CLI, only if it is installed on the machine (and perhaps providing an ability to install Chocolatey CLI, if it is not detected).

Some Chocolatey operations require administrator rights to be properly run (for example, update sources), and it was not viable to have the user elevate every single operation (because they are sometimes automated, and there are issues with parsing live output of elevated programs). Therefore, if the user chooses so, Chocolatey will be installed within UniGetUI, on a non-admin location.
If the user already has Chocolatey, or decides to install chocolatey themselves, UniGetUI can work with system chocolatey, but issues may be expected. For the record, if UniGetUI is installed on a machine with chocolatey already installed, UniGetUI will (or at least should) pick that out as the default chocolatey installation.

The issue with bundling a version into UniGetUI is that it can become outdated, as new versions of Chocolatey CLI is released. This adds work to the maintenance of UniGetUI.

I have an automated workflow on my pc, that updates chocolatey before I build a new version. In fact, I used to do the same thing until I was able to migrate to COM APIs. Asynchronous updates also mean that the CLI output can change, and I wouldn't be able to prevent the users from updating and then having a broken integration with UniGetUI.

In addition, running choco list against the bundled version of Chocolatey CLI, will report different packages as being installed, compared to the machine level installation of Chocolatey CLI.

This shouldn't be a thing, unless you are using bundled chocolatey with WinGet, and system chocolatey on a CLI.