しばたテックブログ

気分で書いている技術ブログです。

PowerShell Galleryがリニューアルしました

PowerShell

f:id:stknohg:20180916151011p:plain

つい先日、PowerShell Core 6.1のリリースと足並みを揃える形でPowerShell Galleryのサイトがリニューアルしました。

公式のアナウンスはコチラです。

blogs.msdn.microsoft.com

リニューアル自体は以前からアナウンスされ、プレビュー版のサイトが公開されてフィードバックを募っていたのが晴れて正式リリースとなった形です。

また、PowerShell Galleryのリニューアルと同時にPowerShellGetのモジュールがVer.2.0.0とメジャーバージョンアップしています。

PowerShell Gallery更新内容

公式のアナウンスからいくつかかいつまんで説明します。

1. Modern UIの採用

サイトのデザインが今っぽく変更され、以前は無かったモバイル向けのデザインも追加されています。

また、各モジュールの情報に対して主要な情報のみ初期表示し、その他の要素については折りたたまれた状態にするといった最適化を図ったそうです。

2. パフォーマンス改善

CDNの利用*1によりモジュールのダウンロード速度が改善されたそうです。
特にアメリカ国外でのダウンロードが大きく改善されているであろうとの事です。

3. マニュアルダウンロード

PowerShell Galleryはもともと内部的にNugetを利用しており、モジュールも内部的にはnupkgの形で保持されています。

今回のリニューアルでこのnupkgファイルを直接ダウンロードできる様になりました。

f:id:stknohg:20180916151101p:plain

インターネットに直接接続できない環境に対してこのnupkgを使い手動でモジュールのインストールをする事ができます。

細かい手順については

を参照してください。

4. Aligning with NuGet

こちらは利用者に直接関係のない話ですが、PowerShell GalleryとPowerShellGet内部で利用しているNugetのバージョンが更新されその改善点も反映されたとのことです。
後述のNuget API Key管理の更新はこの変更があってのことだそうです。

モジュール利用者向けの更新点

最新のPowerShellGet 2.0.0ではモジュール利用者の利便性を高めるために以下の変更が加えられています。

PowerShellGetの更新方法については本ブログの

blog.shibata.tech

を参考にしてください。

インストール時のデフォルトスコープの変更

これまでは、Install-Module、Install-Script、Install-Packageでモジュールやスクリプトをインストールする際のデフォルトスコープはAllUsersであり要管理者権限でした。

PowerShellGet 2.0.0からはデフォルトスコープが以下の様に変更されます。

  • PowerShell 3.0 - 5.1 : コンソールが管理者として実行されている(昇格している)場合はAllUsers、そうでない場合はCurrentUser
  • PowerShell 6.0 - : 常にCurrentUser

この変更に至る経緯については

github.com

を見ると参考になります。

モジュール開発者向けの更新点

今回のリニューアルでモジュール開発者にとっては大きな変更が発生しています。

公式ブログに

Most important: Publishers must update to PowerShellGet module version 1.6.8 or higher to publish to the PowerShell Gallery. Older versions of PowerShellGet are fine for find, save, install, and update functions, but not for publishing.

とある様にPowerShellGetのバージョンが1.6.8以降(現時点では2.0.0しかない)でないとモジュールの公開やバージョンアップ*2が出来なくなりました。

また、セキュリティ強化のために以下の変更が加えられています。

1. API Keyの有効期限

モジュールを公開するために使用するNuget API Keyに有効期限が設けられ、1日、90日、180日、270日、365日のいずれかを指定する必要があります。

既存のAPI Keyは有効期限無期限の"Full access API key"として残されていますが、一度削除すると二度と再作成することはできません。

2. API Keyの画面表示

新しいPowerShell Galleryでは作成したAPI Keyの値は画面表示されることは無く、作成時にクリップボードに保存して値を確認・保存することしかできなくなりました。
API Keyの値を忘れた場合は再作成するしかありません。

3. 複数Keyの作成

これまでは単一のAPI Keyしか持てませんでしたが、新しいPowerShell Galleryでは複数のAPI Keyを持つことができそれぞれに識別名と個別の権限を付与することができる様になりました。

f:id:stknohg:20180916151219p:plain

細かい設定については

をご覧ください。

4. 二要素認証のサポート

PowerShell Galleryで使用するアカウントで二要素認証がサポートされました。
PowerShell Gallery独自の二要素認証ではなく、使用するMicrosoft Accountの二要素認証の仕組みを流用している様で、Microsoft Accountで二要素認証を有効にしている場合はそのままPowerShell Galleryでも有効になっていました。

詳細はコチラをご覧ください。

5. ログインアカウントの変更機能

これまではPowerShell Gallery初回登録時のMicrosoft Accountがログインアカウントとなり変更できませんでしたが、今は変更できる様になりました。

詳細はコチラをご覧ください。

*1:以前はCDNを使っていなかったのか？といった点については明言されていませんが、使ってないことは無いでしょうし、利用方法を改善したものと思われます。

*2:バージョンアップは可能でした。元の文章を思いっきり誤読してました...

PowerShell Core 6.1がリリースされました

PowerShell

公式情報はコチラ。

blogs.msdn.microsoft.com

本エントリでは公式情報をベースに補足を入れる形で説明していきます。

新機能について

公式ブログではPowerShell Core 6.1の新機能として以下の点を挙げています。

1. Windows 10およびWindows Server 2019との互換性強化

公式ブログで、

Compatibility with 1900+ existing cmdlets in Windows 10 and Windows Server 2019

と説明されている様にBuild 17711以降のWindows 10およびWindows Server 2019に対する互換性が強化されています。
具体的にどの点を修正しているかまでは公開されていませんが、PowerShell Core側、OS側両方に修正が入っているものと思われます。

この互換性の強化については、以前に

blogs.msdn.microsoft.com

で説明されており、詳細はコチラのエントリを見ると良いでしょう。

【2018/10/01追記】

この点について別エントリでまとめました。
こちらも併せてご覧ください。

blog.shibata.tech

【追記ここまで】

2. .NET Core 2.1化

PowerShell Core 6.0がリリースされた時のアプリケーション基盤は.NET Core 2.0(ラインタイムバージョンで2.0.4)でしたが、PowerShell Core 6.1では.NET Core 2.1(ラインタイムバージョン2.1.3)に更新されています。

.NET Core 2.1の新機能はコチラに記載されています。

PowerShell Coreとしては主にセキュリティ更新やパフォーマンス改善の部分で恩恵を受けています。

3. サポートプラットフォームの最新化

サポートされるプラットフォームがPowerShell Core 6.0の頃に対して最新化されています。
同時に古いプラットフォームがいくつかEOLとなっています。

現時点でサポートされるプラットフォームは以下。

  • Windows 7/8.1/10
  • Windows Server 2008R2/2012/2012R2/2016 (and 2019 on release)
  • Windows Server Semi-Annual Channel (SAC)
  • macOS 10.12+
  • Ubuntu 14.04/16.04/18.04
  • Debian 8.7+/9
  • CentOS 7
  • Red Hat Enterprise Linux (RHEL) 7
  • openSUSE 42.3
  • Fedora 27/28

以下は非公式のコミュニティサポートのみ

  • Ubuntu 18.10
  • Arch Linux
  • Raspbian (ARM32)
  • Kali Linux
  • Alpine (experimental Docker image coming soon)

以下のLinuxディストリビューションについてはディストリビューション自体がEOLとなったためPowerShell Coreとしてもサポート外となりました。

  • Ubuntu 17.04
  • Fedora 25,26
  • openSUSE 42.2

ちなみに、PowerShell Core 6.0リリースの際に説明した通り、PowerShell Core のサポート ライフサイクルはMicrosoft Modern Lifecycle Policyとなります。

docs.microsoft.com

4. パフォーマンス改善

先述の.NET 2.1化による影響を主としてパフォーマンスが改善されています。
公式ブログでは"Significant"と謳っていますが具体的なベンチマークが公開されているわけではないのでほどほどに受け止めておくと良いでしょう。
(ただし、開発環境に対してパフォーマンス測定ツールが導入されており内部的な計測はされている様です)

【2018/09/16 追記】

いくつかのコマンドレットに対するパフォーマンス計測結果がDocsに記載されていました。

詳細はこちらをご覧ください。

【追記ここまで】

私もすべての改善点を挙げることはできませんが、内部的に.NET Core 2.1の新機能であるSpan<T>を使う修正が入るなどランタイムだけではなくコードベースの改善も幾つかなされています。

以下に幾つかパフォーマンス改善に関するプルリクエストを列記しておきます。

5. Markdown cmdlets

Markdownを扱うコマンドレットが追加されました。
細かい話は

blog.shibata.tech

をご覧ください。

6. Experimental feature flags

試験的な機能追加に備えるための機能が追加されました。
仕様についてはコチラのRFCをご覧ください。

現時点で採用された試験的な機能は無いためこれが役に立つのはもうしばらく先の話となります。

仕組みについてですが、基本的にはpowershell.config.jsonに利用する試験的な機能を記述する形になります。

// RFCのサンプルを例示
{
  "ExperimentalFeatures": [
    "A-Experimental-Feature-name",
    "Another-Experimental-Feature-Name"
  ]
}

機能の側はコマンドレットにExperimental属性を付けることで有効・無効化の対象となります。

// RFCのサンプルを一部改変して例示
[Experimental("A-Experimental-Feature-name", ExperimentAction.Show)]
[Cmdlet(Verbs.Invoke, "WebRequest")]
public class InvokeWebRequestCommandV2 : WebCmdletBaseV2 { ... }

[Experimental("A-Experimental-Feature-name", ExperimentAction.Hide)]
[Cmdlet(Verbs.Invoke, "WebRequest")]
public class InvokeWebRequestCommand : WebCmdletBase { ... }

その他

その他新機能の詳細についてはDocsのリリースノートとGitHubのチェンジログを見るのが一番です。
本ブログでも近いうちにこの内容をまとめたいと思います。

また、公式ブログで触れられていないものの影響が大きそうな点として

あたりが挙げられます。

【2018/10/16追記】

Docsにある新機能・破壊的変更について別エントリでまとめました。

blog.shibata.tech

こちらも併せてご覧ください。

【追記ここまで】

PowerShellの今後について

公式ブログでは今後の方針について一切触れられませんでした。

あくまで私の予測ですが、今後しばらくは現状維持となりWindows 10およびWindows Server 2019との互換性の強化や不具合の改善につとめていくのかな？と思います。

PowerShell Core 6.1で導入されるMarkdown関連機能について

PowerShell

PowerShell Core 6.1 Preview.4からMarkdownを扱う以下のコマンドレットが追加されました。

  • ConvertFrom-Markdown
  • Show-Markdown
  • Get-MarkdownOption
  • Set-MarkdownOption

これらのコマンドレットを使うとMarkdownのドキュメントを解析し、HTMLまたはコンソールに表示することができる様になります。

実装方法は前回説明したThreadJobとは異なりPowerShell Core本体(Microsoft.PowerShell.Utility.dll)に実装されています。
このためWindows PowerShellでこれらのコマンドを利用することはできません。

また内部的にMarkdigを利用しています。

github.com

機能説明

まずは各コマンドの機能説明をします。

ConvertFrom-Markdown

Markdownのファイルまたは文字列を読み込みMicrosoft.PowerShell.MarkdownRender.MarkdownInfo型のオブジェクトに変換します。
Microsoft.PowerShell.MarkdownRender.MarkdownInfo型のオブジェクトは後述のShow-MarkdownでHTMLまたはコンソールに表示します。

-Pathおよび-LiteralPathを指定した場合はファイルから内容を読み込みます。
文字コードはUTF-8であることが期待されており-Encodingパラメーターはありません。

ConvertFrom-Markdown -Path .\sample.md

(sample.mdの内容は以下)

# ヘッダ1

__マークダウン__ の _サンプル_ です。

## ヘッダ2

* Hello
* World

### ヘッダ3

1. Hello
1. PowerShell

#### ヘッダ4

うちのブログ

* [しばたテックブログ](https://blog.shibata.tech) 

##### ヘッダ5

\```
# コードブロックのサンプル
Write-Output "Hello"
\```

###### ヘッダ6

> 引用文です。

既定ではMarkdownはHTMLに変換されます。

f:id:stknohg:20180910225601p:plain

-AsVT100EncodedStringパラメーターを付けるとコンソール表示用にVT100エスケープシーケンスで修飾された文字列に変換されます。

ConvertFrom-Markdown -Path .\sample.md -AsVT100EncodedString

f:id:stknohg:20180910225618p:plain

また、パイプラインから文字列およびSystem.IO.FileInfo型のオブジェクトを受け取ることも可能です。

@"
# ヘッダ1

__マークダウン__ の _サンプル_ です。

## ヘッダ2

* Hello
* World
"@ | ConvertFrom-Markdown

f:id:stknohg:20180910225631p:plain

Get-ChildItem .\sample.md | ConvertFrom-Markdown

f:id:stknohg:20180910231819p:plain

Show-Markdown

ConvertFrom-Markdownで生成したオブジェクトをコンソールもしくはWEBブラウザに表示します。

個人的にちょっとイケてないと思うのですが、このコマンドはHTMLが既定のConvertFrom-Markdownとは逆でコンソール表示が既定となります。
このため以下の様にConvertFrom-MarkdownとShow-Markdownの組み合わせでNGとなるケースが出てしまいます。

# OK
ConvertFrom-Markdown -Path .\sample.md -AsVT100EncodedString | Show-Markdown

# NG : Show-Markdownは既定でコンソール表示なため、ConvertFrom-Markdownで-AsVT100EncodedStringの指定が必要
ConvertFrom-Markdown -Path .\sample.md | Show-Markdown

f:id:stknohg:20180910225652p:plain

f:id:stknohg:20180910225702p:plain

HTMLを表示する場合は-UseBrowserパラメーターを指定してやる必要があり、名前の通り既定のブラウザでHTMLとなったMarkdownの文章を表示します。

# OK
ConvertFrom-Markdown -Path .\sample.md | Show-Markdown -UseBrowser

f:id:stknohg:20180910225713p:plain

f:id:stknohg:20180910225723p:plain

【2018/09/11追記】

最初にPreview.4でこの機能がリリースされてからShow-Markdownが使いにくいというフィードバックがあり、次のリリースのRC.1ではShow-Markdownに-InputObject、-Path、-LiteralPathパラメーターが追加され、このコマンドで直接Markdownを扱うことができる様に改善されています。

github.com

# PowerShell Core 6.1 RC.1より
Show-Markdown -Path .\sample.md

f:id:stknohg:20180911125903p:plain

# PowerShell Core 6.1 RC.1より
@"
# ヘッダ1

__マークダウン__ の _サンプル_ です。

## ヘッダ2

* Hello
* World
"@ | Show-Markdown

f:id:stknohg:20180911130059p:plain

【追記ここまで】

Get-MarkdownOption

Markdownの変換に関する各種設定を表示します。

Get-MarkdownOption

現時点ではMarkdownの各要素をコンソール表示する際の色指定のみ存在します。
今後設定が増える可能性は高いと思われます。

f:id:stknohg:20180910225734p:plain

Set-MarkdownOption

Markdownの変換に関する各種設定を設定します。

Set-MarkdownOption -Header1Color "[4;92m"

f:id:stknohg:20180910225747p:plain

PowerShellではありがちですが、このコマンドで設定した内容は永続化されません。
永続化したい場合はプロファイルにコマンドを記述してください。

何故この機能が追加されることになったのか？

ここからは補足的な内容となります。
興味のある方はご覧ください。

今回追加されたMarkdownに関わる機能は以下Issueを発端とし、

github.com

RFC(Native Markdown Rendering)を経て採用、機能追加されています。*1

github.com

このRFCによれば、

Motivation

Markdown is a common authoring format used by the community. There is no easy way in PowerShell to visualize a markdown document on console. Since the PowerShell help is authored in markdown, these components will be used for rendering help content.

とあり、PowerShell TeamとしてはMarkdownで新しくヘルプドキュメントを作り直したい展望があり、そのためにPowerShell内部でネイティブにMarkdownを解析しレンダリングする機能が必要になったことが根底にあります。

すこし話が逸れますが、PowerShellのヘルプドキュメントはコードコメントかMAMLで書く必要があり、特にMAMLの記述が非常に面倒であるという現状があります。
(私もMAMLは全然書けませんし、正直書く気も起きません...)

この現状を打開するためにPlatyPSといったプロジェクトが存在し、ヘルプドキュメントのMarkdown化は以前から検討されていました。

github.com

まだヘルプドキュメントのMarkdown化は実現していませんが、今回の機能追加を経て順次成されていくのかな？と思います。

現状の課題と展望

先述のRFCを見ればわかりますが、現在はRFCにある機能が全て実装されていませんし、実装されている機能にも幾つか細かいバグがあります。

他にも

「ConvertFrom-MarkdownがあるならConvertTo-Markdownも欲しい。」

といった要望や、

「Markdown関連の機能をモジュールとして切り出すべきでは？」

といった意見もあり、まだまだ課題が多いのが正直なところでしょう。

これらの課題がどう解決されるかはまだ何とも言えません。

最後に

ちょっと長くなりましたがこんな感じです。

機能のあり方に課題は残るものの、利用者目線で見ればこの点を気にする必要は無いでしょう。
PowerShell Teamの思惑を抜きにしてもMarkdownはよく使うものですし追加された機能を活用できる状況は多いのではないかと思います。

*1:RFCを採用したなら3-Experimentalから4-Experimental-Acceptedに移動すべきなのですが、なぜか移動されておらずその理由も不明です... 2018/0913に5-Finalに移動されてました。