Getting started with winget, the Windows package manager


Windows developers have long watched with envy the glut of Linux package managers. Having a simple command line tool like apt or rpm that would install an application and all of its prerequisites makes it easier to install a toolchain; all you need is a script that chains a list of tools together. Hit return and you’re good to go.

This has never been the case in Microsoft environments, at least not before the Azure CLI and ARM models. But they only apply to the cloud or Azure Arc managed systems. They operate at a higher level than tools that install an editor, utility or compiler, delivering complete infrastructures. Windows users have had the option of third-party Chocolatey, leveraging PowerShell and working with native Windows installers, but that means either buying into the Chocolatey ecosystem as an organization or doing everything possible. to find and install the free desktop client.

Presentation of the wing

There is certainly a great demand for a command-line-driven package installer in Windows, and Microsoft is finally taking notice. In 2020, it announced Windows Package Manager and Winget, a package manager integrated with Windows App Installer tools. Currently available to Windows Insiders in a preview version of the App Installer, Winget is also downloadable from GitHub for Windows 10 version 1709 and later. You can also build it from project source code using Visual Studio 2019 with its desktop developer tools for .NET, C ++, and UWP. There is even a separate Insiders program with its own mailing list.

Winget is the first iteration of an integrated package manager for Windows, closely related to various open source alternatives, in particular AppGet. It is built in public on GitHub. It has a similar architecture to most package managers, using application manifests to describe applications and their requirements, with a central managed repository for manifests, each linked to download sites for installers of the software. ‘applications.

Once installed, winget behaves like any other command line tool and can be accessed from the Windows command line or PowerShell. It has a built-in search function which can find a specific package or display the full list of available packages. For the complete list of plans, type winget search. If you want a local catalog, direct the output to a file to get a text file with the current 1350 packages.

Running the winget client

Installing an application from the repository is relatively straightforward. All you have to do is find the name of the app using search and then run winget install. You can use a query as part of the installation instead of a full package name; additional options let you choose specific versions (the default is to install the latest version), how the installer runs, and even where the file should be installed. It’s a quick process, and because apps are installed using standard Windows installers, they can be uninstalled using familiar Windows settings.

You don’t need to run winget as administrator as it wraps around existing installers. So if an application needs administrative privileges, it will use the standard Windows account elevation dialog to request permissions. It is best to run it as a standard user to get these prompts because you can cancel installations that might load software that you do not want to run. If you run winget as administrator, it will install all files with administrator privileges.

Building winget packages

At the heart of a winget package is an application manifesto. This is where developers describe what is needed for their application to run, using a YAML document. Microsoft provides a full specification for YAML in its GitHub repository. This simplifies building a basic manifesto. You need a publisher, app name, version, and license details. They are followed by the installer type and a URI for the installer. Next, provide a list of architectures supported by your application and a SHA256 hash to validate the installer during download.

A full manifesto has a lot more content, supporting everything from a minimal operating system version to a set of search tags that can help you find your app. Future versions will allow you to configure multiple installers, making sure the prerequisites are installed with your code, with winget running each installer in order. However, the current preview only supports one installer.

It is unclear how future versions of Winget will handle multiple installations where applications are already in place. It is likely that it will be able to respond to error messages from supported installers, and it should be able to automatically handle upgrades to newer versions as well as new installations, skipping an installer or an application. is already on the target PC. For now, if you want to install multiple items, it’s best to build a script that wraps multiple winget calls so that the tools are installed in the correct order.

Manifests are automatically validated when submitted to the winget GitHub package repository. You can use the validation command in the winget CLI tool to test a manifest before submission. Once tested, you will add your package to a local fork of the repository, using a defined directory format. Once your fork is set up, use the git commands to commit and send your changes to the GitHub repository, finally using a pull request to submit your package manifest to Microsoft. Microsoft will use the GitHub code review process to process your pull request, initially using automatic validation through Azure DevOps tools, with a final human verification before it’s added to the winget repository and can be uploaded by users.

Working with winget repositories

Currently, Microsoft manages the only winget repository. This makes sense during development, but as it goes into production there will be demand for private repositories as well as third-party support, for example by working with existing services like Chocolatey and providing a way to authenticate against its commercial repositories. A statement in the winget documentation notes that Microsoft is discussing API-based access to other repositories and installation tools, which should allow rapid development of a rich ecosystem of packages from free and paid tools.

By setting up a private repository with tested and approved versions of development tools, a development team can standardize on a single toolchain and a single tool source. This way everyone will be using the same version of an editor or the same linter, reducing the risk of confusion or failure of builds that have been tested on different compilers or using different linkers.

Current versions of winget include experimental features that can be enabled through its settings command, adding JSON flags to the winget configuration file that opens when you call up. winget settings. These include options to update and uninstall apps (which makes it much more like a Linux package manager) and support for using the Microsoft Store. Currently, you cannot access the entire store, only a set of organized utilities.

This is an example of the kind of third-party repository support you can expect from Winget, a targeted list of tools aimed at a limited audience. Don’t expect it to replace the Windows Store anytime soon; With the upcoming release of Windows 10X, the store will remain Microsoft’s preferred route for delivering consumer applications to users’ PCs.

With winget, Microsoft promises to solve many problems of targeted software delivery to developers or power users. Winget is a flexible and simple tool. It’s easy to integrate into setup scripts, can quickly deploy entire toolchains as part of an install image, or support adding consistent tools to a BYOD deployment. It’s worth a look now, especially if you’re using one of the more than 1,300 tools currently in the manifesto and want to automate the setup of your next PC.

Copyright © 2021 IDG Communications, Inc.


Comments are closed.