Chocolatey is a package manager similar to Linux apt and yum to create, update, distribute and remove software packages in a centralized and automated manner.
Two are the platforms at its basis: NuGet and Windows PowerShell. The former is a .NET package manager on its turn, and the former is the well-known integrated shell of the Microsoft Windows world. Available both as a command line tool and with a GUI, Chocolatey is an open source project with three licensing models: free, Pro and Business, with the additional MSP and Architect plans for specific uses.
The free version is the one with the least number of features and without the official support; limitations include not being able to create your own packages, convert existing ones or have the centralized console dashboard. The Pro version is for up to 8 computers and any business usage is forbidden; the price is $96 per year and includes official support via email and advanced features like graphic Package Builder. The Business license is more structured with packages whose price varies according to the number of computers where Chocolatey will be installed. This version doesn’t have any restriction in terms of features and has a complete support. Then we have two editions for specials cases: the MSP one, distributed with at least 200 licences, and the Architect, which is conceived for development purposes and has an aggressive price. You can find a recap table here.
Chocolatey in action
Being a package manager, Chocolatey includes the main features we expect from such a product: installation, update, dependencies management, automated uninstall and auditing. For that, you can deploy a dedicated server, which will also host the packages’ repository.
Chocolatey doesn’t have any high requirements in terms of computational resources, it just needs Windows 7 or later (equivalent to Windows Server 2003 or later), PowerShell 2 or alter and .NET 4.x or later - if not available, it will be automatically downloaded and installed. The installed is a simple script that can be run from a shell (with admin privileges) or PowerShell (documentation here). Once the installation is complete, simply try it by writing choco or choco -?. Should the Internet installation fail, an offline package is available.
Note that the basic installation installs a trial version, and the use of a licence requires an activation procedure. According the version, you can update the platform with a command as simple as choco upgrade chocolatey, exactly as you would do for other packages. After Chocolatey is up and ready, packages can be installed with choco install package-name. A wide assortment of additional options can be passed as parameters, for instance a different installation folder than the default one.
Similarly to Linux, additional parameters can be passed with characters combinations that include -, / and _ according to the type of parameter. For instance single characters options can be called with /; other specific-feature characters are = and =! to evaluate options, -d for debug, -v for the extended description (verbose) and -y for automatic yes to prompts.
Key concepts about Chocolatey
Three are the phases that involve the life of a package: installation, update and removal. Let’s see how to do that.
We’ve seen previously how Chocolatey is based on NuGet: thanks to this platform if can actually perform the installation. NuGet collects the package from the source: it can be a local folder, a network share or a repository on the Internet. Both http and https are supported.
As in Linux, source repositories can be added and removed manually according to needs (eg: you deployed your own and want to add it to the list). Standard installation path is ChocolateyInstall\lib\ and can’t be configured inasmuch is also used to track the life of the package in order to better update or remove it. Indeed, Chocolatey checks whether the package requires any dependencies and creates a registry snapshot before and after the installation, and a special file with all information for the proper removal.
Then the software checks the presence of executable files in the working directory and generates libraries (Shims: they translate API calls and any arguments passed with the command) that are made available the the final package in the \bin folder.
Updating a package happens in a similar fashion: Chocolatey creates a snapshot of the package’s folder before trying to update so that a rollback can be performed if anything goes wrong. Be careful because the snapshot includes only the directory of the package, so any additional integration and external references will be lost.
Lastly, the removal of a package happens by launching the script included in the package’s folder, after backing up the folder itself. Once the procedure is complete, if empty, the folder itself will be removed.
Here’s the syntax to use for each of the three situations:
choco install <pkg|package.config> [<options/switches>]
choco upgrade <pkg|all> [<options/switches>]
choco unistall <pkg|all> [<options/switches>] oppure cunist <pkg|all> [<options/switches>]
Adding a repository:
choco source [list]|add|remove|disable|enable [<options/switches>]
Chocolatey can also work with software already installed on the machine, so it can integrate with the already-present environment and be used to install a certain packages without impacting on any other on the system.
Of course most times we don’t know the exact name of the package to install: the search command comes handy as it helps to search the package locally and remotely. The three main usages are:
choco search <filter> [<options/switches>]
choco list <filter> [<options/switches>]
clist <filter> [<options/switches>]
The last one is a shorteed version of the previous one.
Within Chocolatey, a package is a nupkg file (or a zip file) compiled with NuSpec that is completely autonomous regarding metadata, dependencies and versioning. It’s clearly an advanced version of the simple aforementioned NuGet package as it contains many more additional information required by Chocolatey to run correctly.
First of all, you can create a self-contained package or an automated script: maintaining a package will be easier and more sager with the former, while the latter involves PowerShell to run such script.
The minimum requirement to create packages are NuSpec and XML files that describe the package itself (ie defining dependencies).
The basic command is:
choco new <package_name>
A brief example of a package with http source might be:
$packageName = ‘gurupackage’
$fileType = ‘exe’
$url = ‘http://download.guruadvisor.net/packages/gurupackage.exe’
$silentArgs = ‘-y’
Install-ChocolateyPackage $packageName $fileType $silentArgs $url
The Business version includes a graphic Package Builder, a tool that simplifies a lot the creation of packages: all you have to do is to select the executable file or the zip archive, select the “Create Chocolatey package” button and specify an output folder.
Concluding, Chocolatey integrates perfectly with several automation platform like Ansible, Boxstarter, Chef, PowerShell DSC, PowerShell PackageManagement and others listed here.