tech.guitarrapc.cóm

Technical updates

PackageManagement (aka. OneGet) の利用時の簡単な注意

Windows 10 でデフォルトで入っている PowerShell v5 からは、PackageManagement(以降 OneGet と称しておきます) が利用できるようになっています。*1

OneGetですが、知らないともどかしい気分になることが多いので少し情報を整理しましょう。

なお、ここでは Find-Package とか使い方は説明しません。

いくつか触れておきます。

目次

動作にバグがまだまだある

残念ながら OneGet は 2015/8/28現在の Windows 10 build 10240においてもバグは残っています。期待した動作と違って、気持ち悪いと感じることもあるでしょう。

インストールに失敗してもインストールされた扱い

インストールが気持ち悪い挙動の例です。

  • Install-Package を使ってインストール中にキャンセル、あるいはエラーが起こってもパッケージがインストールされたことになる

通常、インストールがエラーなく成功した場合にのみインストールされることを期待するので、とても気持ちが悪い挙動です。

この場合、一度対象のパッケージをアンインストールすれば ok です。

Uninstall-Package <PackageName>
アンインストールが不完全な場合がある

アンインストールも、プロバイダ側で正確に組まれてないとできなかったりもします。*2

ARP (Add/Remove Program = プログラムと機能に入っているいつものやつです)のパッケージに関しては、swidtag に記述されたアンインストールストリングを呼び出します。そのため「通常のプログラムと機能からのアンインストール」と Uninstall-Packageは同じ挙動ですが、サイレントアンインストールでないことがほとんどです。もどかしい。

Chocolatey から取得したパッケージはもっとひどいことが多く感じるでしょう。Uninstall-ChooclateyPakcage の実装次第とはいえアンインストールできないことも多いのは事実です。特に.exe のインストールが実態だとするともはやアンインストールは期待できなかったりもします

こんな罠もありますが、便利は便利です。

インストール先を任意で選べない

Issue があります。

github.com

が、どうも乗り気じゃないようで.... 世の中のパッケージマネージャーは選べるし、選べて当然だと思うんですけどねぇ。

補足

いくつかOneGet の知っておくといい補足です。知らなくても困ることはあんまりないでしょうが。

OneGet は API基盤

OneGet は、NuGet や Chocolatey、ARPなど 各種プロバイダーソースを統一的にコマンドから扱えるAPI基盤です。

Archived MSDN and TechNet Blogs | Microsoft Learn

複数のプロバイダソースを扱うことを目材してるのを示すように、GitHub リポジトリの Issue では下記の様々なソースをターゲットとして構想されています。

github.com

それを表現するためMSDNブログで使われる表現が以下です。

「OneGet は ただのパッケージマネージャーではなく パッケージマネージャーマネージャーであり、API基盤だ。」

言ってることはかっこいいですが、現時点ではまだまだプロバイダーも足りません。 これからに期待ですね。

なお、Windows 10 リリース時点では以下のソースが標準でサポートされています。

  • MSI
  • MSU
  • BootStrap
  • ARP (Add/remove programs)
  • NuGet
  • Chocolatey

これらを統一したコマンド体系 Xxxx-PackageZzzz で呼び出すのが OneGet ということです。PackageManagement モジュールに含まれる Cmdlet は以下の通りです。

Get-Command -Module PackageManagement
CommandType Name                     Version Source           
----------- ----                     ------- ------           
Cmdlet      Find-Package             1.0.0.0 PackageManagement
Cmdlet      Get-Package              1.0.0.0 PackageManagement
Cmdlet      Get-PackageProvider      1.0.0.0 PackageManagement
Cmdlet      Get-PackageSource        1.0.0.0 PackageManagement
Cmdlet      Install-Package          1.0.0.0 PackageManagement
Cmdlet      Register-PackageSource   1.0.0.0 PackageManagement
Cmdlet      Save-Package             1.0.0.0 PackageManagement
Cmdlet      Set-PackageSource        1.0.0.0 PackageManagement
Cmdlet      Uninstall-Package        1.0.0.0 PackageManagement
Cmdlet      Unregister-PackageSource 1.0.0.0 PackageManagement

ちなみにAPI基盤の例としては、PowerShell モジュールのギャラリー PowerShellGet もNuGet フィードをベースにしています。そして、操作に実際に呼び出すコマンドの裏では OneGet API を呼び出しています。

https://blogs.msdn.com/b/mvpawardprogram/archive/2014/10/06/package-management-for-powershell-modules-with-powershellget.aspxblogs.msdn.com

OneGetが目指している姿

OneGet が目指している姿も示されています。

https://blogs.msdn.com/b/garretts/archive/2015/05/05/8-laws-of-software-installation.aspxblogs.msdn.com

ソフトウェアインベントリと、各種パッケージプロバイダの透過的な扱い。現時点ではまだまだ困難が多いですね。MSI に統一されてたりしたら楽だったんでしょうが... そんなのはナンセンスですね。

目指している姿として、なんとなく把握しておくといいでしょう。

OneGet のイメージと実際のずれを補完したいなら

もし気になる場合、OneGet 開発者の記事を見ておくと持っているイメージとのずれが保管されるかもです。

https://blogs.msdn.com/b/garretts/archive/2015/05/05/10-things-about-oneget-that-are-completely-different-than-you-think.aspxblogs.msdn.com

まとめ

なんとなく OneGet について情報が整理されれば幸いです。まだまだ情報が入り乱れてますね。

次回は、Private NuGet Feed から、自社専用のパッケージソースを構築する方法を見てみましょう。

*1:本当は OneGet という表現を全面に出すのは望ましく思っていないようですが

*2:ひどい