Get to know the Chocolatey package manager for Windows

I’ve administered both Windows and Linux systems for close to two decades now. Honestly, while Linux is a fantastic operating system and very appropriate in many respects for many applications, I’ve long preferred Windows for its generally better ease of use and polish.

But that doesn’t mean I haven’t pined for certain Linux features when using Windows — and a package management system is one of them. Luckily, there are a couple of package management tools for Windows, and best of all, both are open source and free.

The premise behind package management systems

Linux distributions have had package management options for a while. You probably have heard of Red Hat’s RPM (Red Hat Package Management) format, Debian Linux’s apt-get, and the new yum package manager that seems to be infiltrating a lot of distributions these days. At their core, these package management systems seek to achieve the same objective: to automate the installation, configuration, ongoing management and uninstallation of software packages. This includes analyzing a system; determining what packages are necessary to run whatever software you want; finding the latest compatible version of all of the packages; and installing them in the correct order, ensuring they get laid down on the system successfully and that, after the 117 dependencies install, the software is ready to run on the target system. I kid, but only a little bit.

Imagine bringing this automation over to Windows. Say you are moving to a new system and setting it up properly, exactly how you like it. In the process, you are trying to find the latest version of Google Chrome, for example, or any other reasonably popular utility. The procedure you’d likely use is to Google the product name, find the download link, skip past all of the “featured offers” and near malware that most sites like to bundle with their downloads, and then run the installer. After that, you might even discover you downloaded a 64-bit version when you’re working on a machine with a 32-bit version of Windows installed. Or maybe you found an old download link, and there are two newer versions out there. That whole sequence is not exactly taxing, but it is trying.

Imagine, instead, that you could simply say

choco install googlechrome

from a PowerShell command prompt and you would get:

Jonathan Hassell / IDG

...which would be followed by a completely functional installation of Google Chrome. That would save a lot of time, right?

And what if you had software like Google Chrome installed and then wanted to upgrade it? What if you could use a command like

choco upgrade googlechrome

...and get an instant upgrade?

That is the power of package management, and that is what the Chocolatey package manager brings to Windows: a large and expanding selection of carefully curated and maintained software packages that can be brought down and installed on your system with a simple three-word command. As of this writing, there are about 5,300 community-maintained packages, and you can browse and search among them on the web at https://chocolatey.org/packages.

Where Chocolatey really shines is in the process of setting up and deploying new machines. If you have a fairly standard set of software to install — say, Office 2013 or Office 365 ProPlus, some utilities like 7Zip, a web browser such as Mozilla Firefox or Google Chrome, and a few other tools, then you can absolutely script the setup of a new machine.

Just deploy Windows through whatever method you care to use, and then once you have completed the installation and are at an administrative desktop, simply kick off a script that installs Chocolatey and then calls all of your software. Now you can get 70% to 90% of your software installs automated without having to do a bunch of imaging and packaging yourself, and all of the installations are done in a consistent, repeatable, reproducible way — another benefit of scripting in general.

One financial note: Although the basic version of Chocolatey is free for the taking, there of course are upsells and paid versions for businesses that desire more advanced features, like building one’s own packages and managing installations with more granularity. While in this piece I am discussing the free version, be aware that paid versions exist; you can find out more about them at Chocolatey’s pricing page.

The pieces of the Chocolatey puzzle

Let’s see how all of the pieces fit together in this package management system.

• Chocolatey is a package manager that works with Windows — specifically, any version of Windows 7 or later that also has PowerShell installed. This is the vast majority of clients in production environments today. Chocolately uses scripts, along with a specific software package format (more on that in the next bullet), to install applications on your system.
• NuGet is that specific software package format. It has previously been used by Windows software developers to install software dependencies for their own development projects. These were typically libraries, bootstrap utilities, and more that existed as complete packages out on the internet, ready to be reused. NuGet was simply an easy way to get those dependencies put in the right place within individual products.
• PowerShell is the command engine that makes the whole thing tick. It functions as the scripting language and execution environment for all of Chocolatey. Chocolatey uses PowerShell to grab software, packaged in NuGet format, to install applications for your entire system, not just development projects.

To get started on a test system, use one command, straight from the regular command prompt (be sure you have administrative rights to do this):

@powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

This one line of PowerShell actually does quite a few things, as you might expect. Let’s walk through them individually.

• It supersedes any custom profiles you have configured so as to ensure a full namespace is available to this command.
• It sets the execution policy for just this one command to Unrestricted so that scripts that are downloaded from the internet (in the case of this command, that is https://chocolatey.org/install.ps1) can be executed and not be treated as potentially malicious.
• It downloads that .ps1 script from the Chocolatey website, which is a preconfigured set of instructions that PowerShell can use to install the Chocolatey system on the local machine.
• It also sets a PATH entry to the default binary folder for the Chocolatey install, so that you do not have to enter the full path to the Chocolatey commands every time you would like to do any package management tasks. Instead you can just enter “choco” and then whatever you need, and Windows and PowerShell will know where to find it.

The Chocolatey installation process requires the .NET Framework version 4.0 and will attempt to install it automatically as part of that PowerShell script. I have set this up on Windows 7 and Windows 8.1 machines, and that automatic installation of .NET was totally successful. It’s worth noting that some administrators have a deep-rooted aversion to installing multiple versions of the .NET Framework on systems due to potential application compatibility issues and the attendant security patching that is required for each respective version. However, this is an all-or-nothing proposition, and I think the benefits of Chocolatey outweigh the negatives of deploying another framework version.

Chocolatey in action

Chocolatey is essentially an automated deployment wrapper. It does not intercept installations or somehow modify the setup process of an app. Rather, it automates the downloading of a setup file or package and then its execution, while turning off any sort of screen communication from the app (a silent install).  Here is an explanation direct from Chocolatey that goes into a little further detail:

Chocolatey is a software management tool that is also a package manager. It functions fantastically well when the software is all included in the package and it doesn't make use of native installers. However to approach the Windows ecosystem a package manager also needs to know how to manage actual software installations, thus why Chocolatey does that as well. For publicly available packages, copyright keeps from having binaries embedded in packages, so Chocolatey is able to download from distribution points and checksum those binaries.

Some tips:

• The command cinst works instead of choco install to save you some keystrokes and avoid carpal tunnel syndrome. So choco install googlechrome could also be cinst googlechrome.
• choco uninstall packagename removes a package from your system. It only removes the Chocolatey installed instance, so if for example you have a previous Git installation, then install Git from Chocolatey, and then use choco uninstall git to uninstall one of your Git deployments, it will remove the Chocolatey installed instance.
• Want to search for packages but do not want to browse the web? This is common on new server installs. Use choco search packagename to search the Chocolately package feed.
• The command choco outdated will give you a list of all of the packages on your system that have a newer version available from the repository.

The downsides of Chocolatey

As with every tool, there are negatives to Chocolatey. Here are the most important ones.

There is a malware risk to Chocolatey, however slight. Unless you run your own packaging team and set up Chocolatey’s PowerShell scripts to retrieve packages only from your own private repository full of packages you have vetted and trust, you will not be able to remove from your security mind the idea that you are downloading packages from a third-party source. Those packages could well have malware in them, put there either on purpose by a nefarious actor in the contributor and maintenance team or, much more likely, the Chocolatey repository was hacked and malware payloads were inserted into the packages.

To my knowledge and as of this writing, this type of breach has not happened to Chocolatey. But “has not” is not the same thing as “could not” or “will not,” and so there will always be a risk. Caveat emptor.

On the flipside, Chocolatey is very popular, and most of the package maintainers are very diligent about their work. Since the whole shebang is open source, the “many eyes” theorem suggests that problems and breaches are likely to be discovered and mitigated quickly, and the resulting reporting should be transparent.

Package maintenance is not always quick. Remember, Chocolatey depends on a team of volunteer contributors to package up applications. When new versions of the core applications are released, it is not an immediate process to package up the upgrade and make it available in the Chocolatey repository. For more popular applications like web browsers and some utilities, this is not a big issue — for one thing, that software generally has the ability to update itself, making Chocolatey’s upgrade function a moot point. But in general, the more popular the application is, the more active the Chocolatey package maintaining team for that application is. The wait for more obscure packages could be quite a bit longer, or packages could be left abandoned after several years.

Sometimes install locations get screwed up and there’s no way to track them. Because Windows lets software developers lay their bits down on users’ drives pretty much wherever they please, you wind up in situations where Chocolatey wants to put a particular piece of software in one location, but the GUI installer for that program that you would download from the web wants to put the software in another location.

Herein lies the problem: If you install something outside of Chocolatey, especially if that software installs itself in a directory or folder Chocolatey does not know about, then Chocolately will not think you have that software installed — so it will let you enter choco install thatpieceofsoftware and suddenly you have two installations of the same product on the same system. Sometimes that’s not a big deal, whereas in other situations, it cripples the software.

Using Chocolatey with Windows 10’s PackageManagement

Part of the innovating happening in Windows 10 and Windows Server 2016 is the Windows Subsystem for Linux, or WSL. This is essentially a port of Ubuntu Linux and other popular Linux distributions to Windows in a way that runs those Linux distributions as “layers” or subsystems underneath the regular Windows 10 user experience. Regular Linux binaries work, and you can even install the X Windowing System and get separate graphical shells happening. (Who would have thought the long-promised “year of the Linux desktop” would actually be brought to us courtesy of Microsoft?)

This means that the plumbing is already inside Windows 10 to be able to provide a native package manager that works with PowerShell and Linux binaries, opening up a second entire ecosystem of applications to run on Windows 10 machines. That package manager is called, creatively, PackageManagement and it works with Chocolatey repositories, too. In fact, it is more of a “package manager manager,” because it works with multiple repositories and brings all of their capabilities and inventories together with a single tool.

To verify that PackageManagement (which was codenamed OneGet during Windows 10’s initial development) is set up on your Windows 10 system, open a PowerShell prompt with administrative credentials and then type in the following command:

get-command -module packagemanagement

Then, take a look at the universe of commands you have available to you. An example of this is shown here:

Jonathan Hassell / IDG

To find out what repositories work, then call the following command:

get-packagesource

You will probably find that only the regular PowerShell gallery is there. We can add the entire Chocolatey repository with one single command:

get-packageprovider -name chocolatey

To use the Chocolatey source repository by default, use this command:

set-packagesource -name chocolatey

Now let us try to add some software. We can continue to use Chrome as an example. From the get-command example above, we saw that there is a find-package command that ought to find a package in a repository. Let’s search for Chrome:

find-package –name chrome

In the results, you will see quite a few responses, all of them packages of Chrome that are available in Chocolatey repositories. You can install any one of them by using the install-package command:

install-package chrome

Unfortunately, one of the really nice features of raw Chocolatey, the upgrade command, is not available with PackageManagement. Perhaps one day the ability to upgrade software with a single command will be available, but for now, PackageManagement is useful only to install or remove packages. And again, PackageManagement is available only for Windows 10 and Windows Server 2016, because it is dependent on the Windows Subsystem for Linux, which will not be backported to earlier versions of Windows.

It is also important to note that PackageManagement can co-exist with Chocolatey, so you can use whichever option makes the most sense. It is a very nice tool to have in the arsenal and one that especially for power users and developers can make quick work out of application installation and maintenance.

The last word

I suppose the best way to sum up Chocolatey is this: If you need it, you know as soon as you see it, and you want it right now. I’ve long searched for a lightweight tool (read: not System Center) to script software installations and make it easier to stand up development and test environments with the right programs and utilities. Chocolately fills that role admirably and earns bonus points for using PowerShell to get its work done. Check it out now: https://chocolatey.org/.