あなたは私なしですでに抽象化を読んでいると確信しています：
アプリケーションをインストールするためのチョコレート、開発者が依存関係をインストールするためのnuget。
しかし、これは失礼なだけでなく、真実でもありません。
それでは、Linuxの世界からどのような種類のパッケージを知っていますか？ 注意：パッケージマネージャーではなく、パッケージ自体。 最も一般的なものは、OS依存（deb、rpm）または言語依存（通常はtarball）の2つのグループに条件付きで分割されます。 原則として、最初のグループはアプリケーション（ユーティリティ）であり、2番目のグループは依存関係（ライブラリ）であると言えます。 しかし、そうではない場合もあります：OSパッケージにはライブラリがあり、言語パッケージにはユーティリティをインストールするパッケージ（たとえば、pipのstdebまたはnpmのelastalert）があります-それらがグローバルにインストールされている場合、OSパッケージになります。
Windowsに戻ります。
最初は、パッケージ形式も考案しました。 古い形式には、自動化の方法を理解するための十分に高い入力しきい値があったため、古いmsi / msu形式を置き換えるために作成されました（現在、私は絶賛しています）。 一般に、新しい形式はrpmと非常によく似ています。 スペックファイルもあります。 彼の名前はNuGetですが、拡張子は.nupkgです。 このパッケージには、ディレクトリ、ファイル、およびインストールスクリプトがあります。Linuxユーザーにとっては、すべてが馴染み深いものです。
次に、どのような種類のパッケージマネージャーを知っているかを思い出しましょう。 OSの場合、これはapt、yum、...言語の場合：pip、gem、npm、cpan、cpm、...
Windowsの場合はどうですか？ ここで、新しいNuGetについて説明します。 NuGetパッケージはありますが、同じ名前のnuget.exeがあります-これらのパッケージをダウンロードおよび解凍できるユーティリティです。 一般的に、彼女は他の多くのことを行うことができますが、これは議論の範囲を超えています。
どのようなアライメントが得られますか：
Debian：apt（deb）+ pip + npm + gem + ...
RHEL：yum（rpm）+ pip + npm + gem + ...
Windows：nuget（nupkg）+ pip + npm + gem + ...
彼らはmsiのパッケージマネージャーを作成しなかったことに注意してください（これは完全に真実ではありませんが、単純化のためにこれまでのところ）。
そして、ここからLinuxとの違いが始まります。 Windowsの世界には、1つのチームですべてをインストールすることを決めた才能ある男が現れました。 そして、彼はオープンソースのOneGetプロジェクト（PowerShellモジュールバージョンの1つであるPackageManager、= 5.0）の作成を開始しました。
OneGetは、その言語で各パッケージマネージャーと通信できる抽象インターフェイスです。 OneGetは、統合チームのセットを公開しています。 たとえば、Install-Packageコマンドは、さまざまなコマンドのたびにラッパーです。
何が起こるか：複数のパッケージマネージャーをOneGetに接続します。 例：NuGet、PIP、NPM。
さらに、ある種のpythonパッケージを配置する場合は、次のように記述します。
Install-Package < pip->
OneGetはこれを以下に変換します。
pip install < pip->
次に、NuGetパッケージをインストールして実行します。
Install-Package < nupkg->
今回は、コマンドの呼び出し：
nuget install < nupkg->
嘘をついた。 実際、Install-Packageはこれらのコマンドをバックグラウンドで呼び出しません-パッケージマネージャーは使用されなくなりました。 食物連鎖から脱落した。 代わりに、外部パッケージを管理するための専用のパッケージプロバイダーがインストールされます（PowerShellプラグインを読んでください）。 そして、これらのプロバイダーは、通常のパッケージマネージャーではなく、インストールのタスクに従事しています。 そして、OneGetはそれらのボスです。 依存関係はプロバイダー自体によって監視されます。
ここでは、3番目のNuGet-NuGetパケットプロバイダーについて説明します。 記事の冒頭から、私はあなたの脳を吹き飛ばすことを夢見ていた：NuGetは、NuGetパッケージ（.nupkg）を管理するためにNuGetパッケージマネージャー（nuget.exe）を置き換えるパッケージプロバイダーです。
これは非常に重要なポイントです。 古いパッケージマネージャーには、それぞれ独自のリポジトリのリストがありました（Windowsの用語ではソース）。
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/<_>
または：
PS C:\> gem sources *** CURRENT SOURCES *** https://rubygems.org
OneGetはそれらに依存していませんが、それらを置き換えたプロバイダーに依存しています。 そして、リポジトリのリストは誰にとっても同じですが、外部データベースキーとの類推により、リポジトリが誰に属しているかを示しています。
まず、パケットプロバイダーのリストを確認します。
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
そして今、私たちはリポジトリが誰に属しているかに注目します：
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/
ここで一時停止し、奇妙なパッケージプロバイダーの1つであるPowerShellGetに気を取られます。 このプロバイダーは、PowerShell自体のモジュールをインストールするように設計されています。 PowerShell 2（PackageManager（別名OneGet）が登場する前から）に登場しました。 しかし、それらは互いに同等ではありません。 PowerShellGetは、OneGetのようなパッケージプロバイダーマネージャーではなく、独自の種類のパッケージのみを作成できる通常のパッケージプロバイダーの1つです。
パッケージのタイプは.nupkgで、その内容はPowerShellモジュールです。 したがって、PSGalleryリポジトリがNuGet形式であることに驚かないでください。
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 : {}
これで、次の微妙な点に気付くことができます。PackageManagerのリポジトリのリストは、Get-PSRepositoryではなく、Get-PackageSourceコマンドによって実行されます。
実際、このモジュールの作業は、上で述べたように、PowerShellモジュールをインストールすることです。 インストールキットには、新しいコマンドレットの登録も含まれています。 このコマンドレットは、リポジトリを登録するときに追加のフィールドを提供します（たとえば、PublishLocation）。 標準のコマンドレットを使用する場合、これは表示されません。
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/]...}
最後の投稿：チョコレート。
ChocolateyはNuGetのアドオンだとみんなが言っています。 そのように見えますが、完全ではありません。 Chocolateyは同じ仕様を使用していますが、完全ではありません。 完全なパッケージの代わりに、多くの場合、.msiなどをダウンロードして、その後のサイレントインストールを使用します。 つまり、NuGetパッケージプロバイダーまたはnuget.exeパッケージマネージャーはネイティブのNuGetパッケージのみをインストールしますが、Chocolateyはそれらと他のユーザーがインストールできないものをインストールします。 したがって、Chocolateyパッケージベースは、NuGetベースと比較して非常に印象的です。 したがって、Chocolateyパッケージには非常に多くのスクリプトがあります。
お気付きかもしれませんが、ChocolateyとChocolateyGetの2つのプロバイダーがあります。 最初は、その場しのぎの仮設です。 2つ目は公式プロバイダーで、最近公開されました。 さて、バージョンごとに表示されます。