PowerShell CoreからAnacondaを使用できるようにする方法

Anacondaを設定して、conda initとすると一通り、PowerShell Coreを含めたPowerShell用の設定もしてくれるのだが、この方法はPowerShellを立ち上げると毎回Anacondaが初期化されてしまう欠点がある。PowerShellで毎回Pythonを使うのであれば問題ないのだが、個人的な使用ケースとしてはPowerShellスクリプトのみで完結することも多く、これは非効率的になってしまう。

そのため、Initialize-CondaというCmdletを作成することにした。内容的な以下のような感じ。C:/Path/to/CondaをAnacondaの場所に変える。(GistでWindows版Linux版を取得可能。)

function Initialize-Conda
{
	$CONDA_ROOT_DIR = "C:/Path/to/Conda" # Change this
        [System.Environment]::SetEnvironmentVariable("CONDA_EXE", "$CONDA_ROOT_DIR/Scripts/conda.exe", [System.EnvironmentVariableTarget]::Process)
	[System.Environment]::SetEnvironmentVariable("_CE_M", "", [System.EnvironmentVariableTarget]::Process)
	[System.Environment]::SetEnvironmentVariable("_CE_CONDA", "", [System.EnvironmentVariableTarget]::Process)
    [System.Environment]::SetEnvironmentVariable("_CONDA_ROOT", "$CONDA_ROOT_DIR", [System.EnvironmentVariableTarget]::Process)
        [System.Environment]::SetEnvironmentVariable("_CONDA_EXE", "$CONDA_ROOT_DIR/Scripts/conda.exe", [System.EnvironmentVariableTarget]::Process)

        Import-Module -Scope Global "$Env:_CONDA_ROOT/shell/condabin/Conda.psm1"
        conda activate base
}

環境変数の設定が冗長になっているのは、通常の変数はスクリプト外にスコープを持たないため。.NETのSetEnvironmentVariableprocessのスコープで初期化することにより対応している。(LinuxではCONDA_EXE_CONDA_EXE$CONDA_ROOT_DIR/bin/condaとすること。)

尚、Add-CondaEnvironmentToPromptを使うとプレフィックスとしてConda環境をプロンプトに追加することができるが、挙動が曖昧だったので、今回は割愛している。

これに対応するPSD1は以下の通り。(Gistでも公開。)

@{
    RootModule = 'Conda.psm1'
    ModuleVersion = '1.0.0.0'
    FunctionsToExport = @(
            'Initialize-Conda'
        )
    CmdletsToExport   = '*'
    VariablesToExport = '*'
    AliasesToExport   = '*'
    GUID = '23421dee-ca6f-4847-9c93-1268c629964a'
    Author = 'Hideki Saito'
    Description = 'Anaconda Initializer'
    PowerShellVersion = '6.0'
    CompatiblePSEditions = 'Core'
    Copyright = '(c) 2019 Hideki Saito. All rights reserved.'
    PrivateData = @{
        PSData = @{
            ProjectUri = ''
            ReleaseNotes = ''
        }
    }
}

このファイルをそれぞれConda.psm1Conda.psd1として、Documents\PowerShell\Modules\Conda以下(Linuxでは~/.local/share/powershell/Modules/Conda)に配置すると、Initialize-Condaを読み出せるようになる。

PowerShell Core + イベント管理

これまで2002年より、Sakura-Conのゲストリレーションでスタッフをするにあたり、数々の技術を使用し、イベント計画などを立ててきました。過去には、Org-modeや小型のPythonスクリプトなどを使用してきましたが、今年は、PowerShell Coreを使用し、システムを構築しました。これまでに、PowerShellを使用して、多岐にわたるシステムを構築し、例えばカラオケ歌唱データの集計などがその一例で、他の領域での使用も検討していました。

目的

今回の目的としては、中核的なソリューションとして次を検討しました。

  • イベントスケジュールデータの集計と、可用性を高めたデータの作成。
  • カレンダーデータなどへの他の有用なデータ形式への変換の提供。

PowerShell Coreを選択した理由は以下のような理由からです。

  • LinuxとWindowsを使用している関係上、複数のプラットフォームで動作できる環境が重要でした。Androidで動けばなおプラスですが、この点に関してはUserLAndなどの環境を使用することで可能でした。(尚、Androidで使用する場合は、このようなキーボードの使用がおすすめです。
  • オフラインで使用可能なこと。イベント会場などではインターネット接続が劣悪になることがあり、インターネット接続なしでも使用できることが重要でした。

構成と内容

最初に作成したモジュールはスケジュールシステムより、データを取得するためのシステムでした。スケジュールシステムは、データを取得するためのAPIを持っておらず、この部分に関してはSeleniumを使用し、データを抽出しました。

Seleniumを使用したデータの抽出(守秘事項のため、使用しているソリューション名に関しては伏せてあります。)

Seleniumを使用してデータを取得するのには800件のエントリーで約30秒を要します。(実際に使用するデータはその8分の1程度。)SeleniumモジュールにおいてはUI上で必要な情報が存在している場所まで移動し、結果をDOMより抽出するようなものです。これはC#でプログラムしました。SeleniumはLinuxとWindowsでドライバが提供されているため、これはクロスプラットフォーム動作が可能です。(こちらは、Androidでは動きませんが、Androidで動作するドライバと対応するブラウザがあれば恐らく可能です。)

このシステムは以下のようなデータ構造を列として出力します。

   TypeName: SakuraCon.Relations.Data.Event
Name        MemberType     Definition
----        ----------     ----------
End Time    AliasProperty  End Time = EndTime
Event Title AliasProperty  Event Title = EventTitle
Start Time  AliasProperty  Start Time = StartTime
Equals      Method         bool Equals(System.Object obj)
GetHashCode Method         int GetHashCode()
GetType     Method         type GetType()
ToString    Method         string ToString()
EndTime     Property       datetime EndTime {get;set;}
EventId     Property       string EventId {get;set;}
EventTitle  Property       string EventTitle {get;set;}
Notes       Property       string Notes {get;set;}
Rating      Property       string Rating {get;set;}
StartTime   Property       datetime StartTime {get;set;}
Type        Property       string Type {get;set;}
Venue       Property       string Venue {get;set;}
Duration    ScriptProperty System.Object Duration {get=($this.EndTime - $this.StartTime);}

これに加え、以下のようなps1xmlを定義しました。

<Types>
    <Type>
        <Name>SakuraCon.Relations.Data.Event</Name>
        <Members>
            <MemberSet>
                <Name>PSStandardMembers</Name>
                <Members>
                    <PropertySet>
                        <Name>DefaultDisplayPropertySet</Name>
                        <ReferencedProperties>
                            <Name>Event Title</Name>
                            <Name>Venue</Name>
                            <Name>Type</Name>
                            <Name>Start Time</Name>
                            <Name>End Time</Name>
                            <Name>Duration</Name>
                            <Name>Notes</Name>
                        </ReferencedProperties>
                    </PropertySet>
                </Members>
            </MemberSet>
            <AliasProperty>
                <Name>Event Title</Name>
                <ReferencedMemberName>EventTitle</ReferencedMemberName>
            </AliasProperty>
            <AliasProperty>
                <Name>Start Time</Name>
                <ReferencedMemberName>StartTime</ReferencedMemberName>
            </AliasProperty>
            <AliasProperty>
                <Name>End Time</Name>
                <ReferencedMemberName>EndTime</ReferencedMemberName>
            </AliasProperty>
            <ScriptProperty>
                <Name>Duration</Name>
                <GetScriptBlock>($this.EndTime - $this.StartTime)</GetScriptBlock>
            </ScriptProperty>
        </Members>
    </Type>
</Types>

実際の運用では、このデータをClixmlとして出力し、後ほど読み込めるようにします。PowerShellではこれを可能にする便利なCmdletが用意されています。

$schedule | Export-Clixml schedule.xml

これを読み込むのも容易です。

$schedule = Import-Clixml schedule.xml

これにより、出力されたXMLは取得したデータのスナップショットになるので、オフラインでのアクセスが可能になります。

このデータをもとに、CSV (スケジュール情報等を集計するのに使用) する他、iCalendarなどのフォーマットを出力し、Google Calendarに入力することが可能になります。

このデータ構造により、Where-Objectを使用することにより、必要な情報を取り出すことができるようになります。例えば、「6C」で行われるイベントを知りたい場合は以下のようになります。

$schedule | ?{ $_.Venue -eq "6C" }

これに加え、以下のようなスクリプトを組み合わせました。

function Get-ScNextEvent {
    param(
        [parameter(Mandatory = $true, ValueFromPipeline = $true)]
        $Schedule,
        [parameter(Mandatory = $false)]
        [uint] $Hour = 1
    )
    $result = $Schedule | Where-Object { ($_.StartTime -ge [DateTime]::Now) -and ($_.EndTime -le [DateTime]::Now.AddHours($Hour))}

    return ($result | Sort-Object StartTime)
}

function Get-ScCurrentEvent {
    param(
        [parameter(Mandatory = $true, ValueFromPipeline = $true)]
        $Schedule
    )
    $result = $Schedule | Where-Object { ($_.StartTime -ge [DateTime]::Now) -and ($_.EndTime -le [DateTime]::Now)}

    return ($result | Sort-Object StartTime)
}

これにより、次のイベントや、現在進行中のイベントに関する情報を検索することができます。

他の分野でのPowerShell Coreの使用

PowerShell Core`はスケジュール管理以外の分野でも使用しました。他の部分で使用したのは定形文書を生成する管理システムです。ほとんどの定型文書はLaTeXソースとして生成されているため、コマンドラインより、パーソナライズされた情報を読み込む形式になっています。PowerShellはCSVをデータ構造に変換する仕組みを持っているため、必要な引数はCSVでまとめました。

Windowsでのコマンドラインの文字列の扱いには難があるため、これをWindowsで実行する場合にはWindows Subsystem for Linux (WSL)を使用する必要がありましたが、PowerShell CoreはLinuxでも動作するため、同じモジュールやスクリプトをそのまま使用することが可能でした。

これにより、20通を30秒程度で生成できます。

まとめ

PowerShell Coreにより、クロスプラットフォームな、一貫した環境をリレーション部内で使用する必要のある一部の情報の処理で使用しました。

今後はこのシステムを拡張し、スケジュールの競合探知、負荷確認や人員管理などにも適用できるようにしていく予定です。

PowerShell Core 6.0

PowerShell Core 6.0がリリースされました。ダウンロードはGitHubより各プラットフォーム用に公開されています。尚、インストールは全く別の場所に行われますので、既存のWindows PowerShellを残したまま行えるどころか、ZIPファイルでも提供されていますので、インストーラーを実行する必要でさえありません。)

PowerShell CoreはWindows PowerShellのオープンソース、クロスプラットフォーム版で、今後はWindows PowerShellの開発は5.1を最後のバージョンとし、メンテナンス程度になり、こちらの方に注力していくようです。

Windows PowerShellは.NET Frameworkベースになっていますが、PowerShell Coreは、.NET Core、正確には.NET Standardベースのものになっています。そのため、.NET Standardに準拠したライブラリなどは読み込める場合もありますが、Active Directoryなど、一部の機能は使用できませんので、そういった場合はWindows PowerShellと平行して使用することになるかと思います。

PowerShell Coreの何がいいのか?

特にLinuxやWindowsなど複数のプラットフォームを使用している場合において、同様の使用感、及び、スクリプト構文でCUIを利用することができます。尚、execなどの呼び出しに失敗し、挙動がおかしくなる場合があるので、Linux上でpwshに対してchshを行うのはおすすめできません。(目立ったところではSSHのスクリプト実行に失敗したり、Dropboxがゾンビ状態になったりします。)

.NET CoreのモジュールをCUIより呼び出すことが可能なので、例えば以下の要な構文が使えます。

(New-Guid).ToString().ToUpper()

この構文では、New-GuidはPowerShellのCmdletを使用していますが、これは[Guid]::NewGuid()とすることもでき、同じ形式の出力になります。

[Guid]::NewGuid().GetType() -eq (New-Guid).GetType()
True

実際はCmdletの実体は.NETのライブラリなので、内部的には同じような構造になっています。

Cmdletは例えば以下のような構成になっています。

using System.Management.Automation;

namespace cmdlettest
{
    [Cmdlet(VerbsCommon.Get, "Hello")]    
    public class TestModule : PSCmdlet
    {
        [Parameter(Position = 1)]
        public string Message { get; set; } = string.Empty;

        protected override void EndProcessing()
        {
            var output = "Hello World";
            if (Message != string.Empty)
                output += ", " + Message;
            WriteObject(output);
            base.EndProcessing();
        }
    }
}

これをコンパイルし、モジュールとして読み込むことで、Get-Helloのコマンドが使えるようになり、コマンドラインのパーシングなども自動で制御してくれます。もちろん一度コンパイルすると依存として読み込んでいる他のライブラリにプラットフォームの要件がない限りはPowerShell Coreを使用することのできる全ての環境で使用できます。

PowerShell Coreをダウンロードしたらまず行うべきこと

WindowsPSModulePathの導入

Windowsで使用している場合、以下のコマンドでWindowsPSModulePathを導入しておくと便利かも知れません。Windows PowerShellにより提供される一部のライブラリを使用できるようになります。

Install-Module WindowsPSModulePath -Force

ユーザーレベルで入れたい場合は以下のようにもできます。

Install-Module WindowsPSModulePath -CurrentUser -Force

その後、これは以下のコマンドで有効にできます。

Add-WindowsPSModulePath

尚、スタートアップファイルは$PROFILEですので、こちらに格納することによりPowerShell起動時に自動的に読み込まれます。

ヘルプファイルの更新

PowerShell Coreでは詳細なヘルプ情報を参照することができます。(UNIX系シェルでいうmanページのようなものです。)

これらのドキュメントは更新する必要があります。それを行うにはUpdate-Helpコマンドを使用します。このコマンドはAdministrator権限(Windows)、root権限(Linux等)で行う必要があります。(尚、Update-Helpが失敗する場合-Forceオプションをつけてやるとうまく行くかも知れません。)

どうしても更新が失敗する場合(UI Culture系の例外が発生する場合)それを無視する設定が必要になります。(日本語のヘルプはないので、英語のロケールを優先指定します。)

 -Force -ErrorAction SilentlyContinue -UICulture en-US, ja-JP

更新を行うと、例えばGet-Help Get-Processなどで参照できる他、Get-Process -?で行うこともできます。

最後に

PowerShell Coreがリリースされたことにより、Windows以外のプラットフォームでもPowerShellの利便性が享受できるようになります。スクリプトはプラットフォームを超えて動作する他、.NET Coreを使用して独自のCmdletを記述することができます。

スクリプト開発環境も整備されており、Visual Studio及び、Visual Studio Codeでスクリプトのデバッグができるようになっています。(Cmdletに関しても上記のように実体は.NETライブラリなので、.NET Core開発環境で開発可能。)

これまで特にWindowsとLinux間など共通のシェルスクリプト的な使い方ができなかったので、この点が便利です。(Windows上でUNIX系シェルを使用するにしても、WSLはほとんど別環境ですし、bashやCygwinなどもOSとしての作法が違うため、不便さがありました。)

NuGet経由で拡張が可能など、.NET Coreの機能が利用できるなど、便利な使い方ができそうです。