Terminology OneGet, NuGet, Chocolatey, PowerShellGet - we break it down

In this article I want to help understand the structure of package managers under Windows. The article is aimed more at those who, like me, came from the world of Linux, where it is customary to go into understanding processes below the level of abstractions.

I am sure that you have already read the abstractions without me:

chocolatey to install applications, nuget to install dependencies by the developer.

But this is not only rough, it is also not true.

So, what types of packages do we know from the Linux world? Attention: not package managers, but the packages themselves. The most common are conventionally divided into two groups: OS-dependent (deb, rpm) or language-dependent (usually, tar-bols). In principle, we can say that the first group is applications (utilities), and the second are dependencies (libraries). But sometimes this is not the case: there are libraries among OS packages, and there are packages among language packages that install utilities (for example, stdeb in pip or elastalert in npm) - if installed globally, it will turn out as an OS package.
')
Go back to Windows.

Initially, the package format was also invented here. It was made to replace the old msi / msu format because the old format had a rather high input threshold for understanding how to automate it [it is quite likely that I am raving]. In general, the new format is very similar to rpm. It even has a spec file. His name is NuGet, but the extension is .nupkg. Inside this package there are directories, files and installation scripts - all of us, Linux, are familiar and familiar.

Now let's remember what package managers we know. For OS, this is apt, yum, ... For language: pip, gem, npm, cpan, cpm, ...
What is windows? Here we get to know the new NuGet. There is a NuGet-package, and there is nuget.exe of the same name - a utility that can download and unzip these packages. In general, she knows a lot more, but this is beyond the scope of the issue under discussion.

What is the deal we get:

Debian: apt (deb) + pip + npm + gem + ...
RHEL: yum (rpm) + pip + npm + gem + ...
Windows: nuget (nupkg) + pip + npm + gem + ...

Please note that for the msi package manager it was not created (this is not quite the case, but for the sake of simplicity so far).

And here begins the difference from Linux. Some talented guy appeared in the Windows world who decided that he wants to install everything as a team. And he began writing the open-source OneGet project (its proprietary name: PackageManager, which is one of the PowerShell modules of version> = 5.0).

OneGet is an abstract interface that can talk to each package manager in its own language. OneGet publishes a set of unified commands for us. For example, the Install-Package command, which is a wrapper every time for different commands.

What happens: we connect several package managers to OneGet. For example: NuGet, PIP, NPM.

Further, if we want to put some python package, then we write:

Install-Package < pip-> 

OneGet converts this to:

 pip install < pip-> 

And now we want to put the NuGet package and run:

 Install-Package < nupkg-> 

This time the team called:

 nuget install < nupkg-> 

I lied. In fact, Install-Package does not call these commands in the background - package managers are no longer used. Dropped out of the food chain. Instead, specialized package providers are installed (read the PowerShell plugins) to manage foreign packages. And these providers are engaged in the installation task instead of the usual package managers. And OneGet is their boss. Dependencies are monitored by the providers themselves.

And here we get acquainted with the third NuGet - NuGet-packet provider. From the very beginning of the article, I dreamed of blowing up your brain: NuGet is a package provider that replaced the NuGet package manager (nuget.exe) to manage NuGet packages (.nupkg).

Here is a very important point. The old package managers each had their own list of repositories (Source in Windows terminology):

 PS C:\> nuget source list Registered Sources: 1. nuget.org [Enabled] https://api.nuget.org/v3/index.json 2. ABC [Enabled] http://<___IP>/artifactory/api/nuget/<_> 

Or:

 PS C:\> gem sources *** CURRENT SOURCES *** https://rubygems.org 

OneGet does not rely on them, but on the providers that replaced them. And the list of repositories is the same for everyone, but with an indication of who owns which repository - by analogy with the foreign keys of the database.

First we look at the list of package providers:

 PS C:\> Get-PackageProvider Name Version DynamicOptions ---- ------- -------------- Chocolatey 2.8.5.130 SkipDependencies, ContinueOnFailure, ExcludeVers ChocolateyGet 1.0.0.1 AdditionalArguments msi 3.0.0.0 AdditionalArguments msu 3.0.0.0 NuGet 2.8.5.208 Destination, ExcludeVersion, Scope, SkipDependen PowerShellGet 1.0.0.1 PackageManagementProvider, Type, Scope, AllowClo Programs 3.0.0.0 IncludeWindowsInstaller, IncludeSystemComponent 

And now we look to whom the repository belongs to:

 PS C:\> Get-PackageSource Name ProviderName IsTrusted Location ---- ------------ --------- -------- nuget.org NuGet False https://api.nuget.org/v3/index.json PSGallery PowerShellGet False https://www.powershellgallery.... chocolatey Chocolatey False http://chocolatey.org/api/v2/ 

Now I will pause and get distracted by one of the strange package providers - PowerShellGet. This provider is designed to install PowerShell modules. It appeared in PowerShell 2 - even before the arrival of the PackageManager (aka OneGet). But they are not equal to each other. PowerShellGet is one of the ordinary package providers who can only make their own type of packages, and not a manager of package providers like OneGet.

Its package type is .nupkg, the contents of which are PowerShell modules. So do not be surprised that its PSGallery repository has the NuGet format:

 PS C:\> Get-PSRepository -Name "PSGallery" | Format-List * -Force Name : PSGallery SourceLocation : https://www.powershellgallery.com/api/v2/ Trusted : False Registered : True InstallationPolicy : Untrusted PackageManagementProvider : NuGet PublishLocation : https://www.powershellgallery.com/api/v2/package/ ScriptSourceLocation : https://www.powershellgallery.com/api/v2/items/psscript/ ScriptPublishLocation : https://www.powershellgallery.com/api/v2/package/ ProviderOptions : {} 

And now you may have noticed the following subtlety: the list of repositories in the PackageManager is done with the command Get-PackageSource, not Get-PSRepository.

The fact is that the work of this module, as I said above, install PowerShell modules. The installation kit includes registration of new cmdlets, which he did. This cmdlet provides additional fields when registering a repository (for example, PublishLocation). This is not visible if you use the standard cmdlet:

 PS C:\> Get-PackageSource -Name "PSGallery" | Format-List * -Force Name : PSGallery Location : https://www.powershellgallery.com/api/v2/ Source : PSGallery ProviderName : PowerShellGet Provider : Microsoft.PackageManagement.Implementation.PackageProvider IsTrusted : False IsRegistered : True IsValidated : False Details : {[ScriptPublishLocation, https://www.powershellgallery.com/api/v2/package/], [InstallationPolicy, Untrusted], [PackageManagementProvider, NuGet], [ScriptSourceLocation, https://www.powershellgallery.com/api/v2/items/psscript/]...} 

Last: Chocolatey.

That's all they say that Chocolatey is a superstructure over NuGet. It is like that, but not quite. Chocolatey uses the same specs, but not completely. Instead of a full package, it often uses downloading .msi or anything else and the subsequent silent installation. That is, while NuGet batch provider or nuget.exe package manager installs only native NuGet packages, Chocolatey installs them + everything that others cannot install. Therefore, the base package Chocolatey so impressive compared to the base NuGet. And so there are so many scripts in Chocolatey packages.

You may have noticed that there are two providers, Chocolatey and ChocolateyGet. The first is a homemade makeshift. The second is the official provider that just recently came out. Well, you see by version.