前回、PowerShellからWebDriverを経由してWebブラウザを操作する方法として「Selenium」モジュールを使う例を取り上げた。実はこのモジュールを利用するという選択にはいくつかの“判断”があった。今回はその辺りの経緯を説明しておこう。
→連載「PowerShell Core入門 - 基本コマンドの使い方」の過去回はこちらを参照。
PowerShellからMicrosoft Edgeを操作する調査を開始
PowerShellからMicrosoft Edgeを操作する方法を調べ始めると、Seleniumの存在を知っていても知らなくても、そう遠くない段階で次の2つの選択肢に行き着くと思う。
- SeleniumのC#ライブラリをPowerShellから使う
- PowerShell Seleniumモジュールを使用する
「SeleniumのC#ライブラリをPowerShellから使う」方法はパワフルだ。Seleniumのパワーをフルに利用できるし、最新のSeleniumの恩恵に預かることができる。反面、コードは複雑になりがちだ。半分C#みたいなスクリプトになるので、PowerShellのお手軽感はかなり減る。人によっては、こちらの方法は“ノーサンキュー”となるだろう。
PowerShellで手軽にコトを済ませたいと考えるユーザーの多くは「PowerShell Seleniumモジュールを使用する」方法を選択するだろう。こちらなら、用意されている専用のコマンドレットを使うことでWebブラウザを操作することができる。このお手軽感は捨てがたい。
PowerShell Seleniumモジュールを使う
PowerShell SeleniumモジュールはGitHub.comでホスティングされており、次のページからドキュメントなどを含めた各種データにアクセスすることができる。
今のところ、このモジュールを使うのが最も簡単な方法なのだが……実は、ここにはいくつかの問題がある。オープンソースのサードパーティ製ソフトウエアを使う際には結構遭遇する問題でもあるので、そうした場合に、どうやって利用までの判断を下していくかをステップ・バイ・ステップで追ってみよう。
PowerShell Seleniumモジュールはバージョンが2系列ある
まず、どの辺りが問題になるのか。ここで、Seleniumモジュールのバージョンを確認してみよう。PowerShell GalleryでもGitHub.comでも確認できるが、Seleniumモジュールには次のバージョンが存在している。
- 4.0.0-preview3
- 4.0.0-preview2
- 4.0.0-preview1
- 3.0.1
- 3.0.0
現行バージョンは「3.0.1」であり、パラメータを指定せずにInstall-Moduleでインストールすればバージョン3.0.1がインストールされる。しかし、すでにバージョン4がプレビュー版で存在しているので、今から使い出すならそちらの方がよいようにも思える。今後4.0.0の正式版が出るなら、今からプレビュー版を使っておくというのはロジカルな選択肢だ。
しかし、4.0.0プレビュー版の最新版となる「4.0.0-preview3」の最終更新日が2021年3月7日になっている点に注目したい。執筆時点で1年半ほどが経過している。ちょっと嫌な予感がする。
すでに開発は停止している
「adamdriscoll/selenium-powershell: PowerShell module to run a Selenium WebDriver.」を確認してみると、README.mdに次のようなコメントがあることに気付く。
- Looking for Maintainers - I haven't been able to able to keep up with the issues on this repo. If you are interested in becoming a maintainer, please let me know. - Adam
メンテナーを探しています - このソフトウエアの開発継続が困難な状態が続いています。開発の引き継ぎに興味がある方は連絡ください。アダム(筆者による意訳)
理由は掲載されていないのでわからないが、オリジナル開発者はこのモジュールの開発を継続できないとし、興味があるユーザーに引き継がないかと呼びかけている。このまま引き継ぐ人が現れなければ、このモジュールは二度とバージョンアップが行われなくなる可能性が高い。
現れる選択肢 その1
ここでユーザーは、このモジュールに関していくつかの選択を迫られる。まず、次の2択だ。
- PowerShell Seleniumモジュールの使用を諦める
- PowerShell Seleniumモジュールの使用を続ける
どちらを選ぶかはユーザーの置かれている状況に左右される。取り組んでいるのが長期のプロジェクトなら、ここで「使用を諦める」という選択肢を選ぶケースが多いだろう。アクティブではないモジュールを採用することにはリスクが伴うからだ。その場合、多少面倒だがC#経由でSeleniumを使う方法から、簡易的な独自モジュールを開発して使うといった選択をするのではないかと思う。
現れる選択肢 その2
状況によっては、とりあえずPowerShell Seleniumモジュールを使うことを選ぶこともあるだろう。現状、使えるには使えるわけで、その利便性は捨てがたい。こちらを選んだ場合、今度は次の選択肢について考えなければならない。
- バージョン3.0.1を使う
- バージョン4.0.0-preview3を使う
もう新しいバージョンはリリースされない。そう考えるとどちらもでよいような気がする。ここから先は実際に使ってみて比較するしかないのだが、それぞれのバージョンを使ってみると次のような特徴が見えてくる。
- バージョン3.0.1 - ドキュメントに類するものがある(「selenium-powershell/README.md at master · adamdriscoll/selenium-powershell」「selenium-powershell/ChangeLog.md at master · adamdriscoll/selenium-powershell」)。ドキュメントを参考にすればほぼやりたいことはできる
- バージョン4.0.0-preview3 - ドキュメントがない。ただし、整理が行われていてバージョン3よりも洗礼されている印象を受ける。4の方が統一性のあるスクリプトが書ける気がする
上記をどう判断するかはユーザー次第だ。ともかくすぐに動くものを作りたいならバージョン3を、ある程度長く使っていくつもりならバージョン4を、といったところだろう。
大抵、この調査には十分な時間をかけられない。場合によっては数時間の調査と実験で、どちらを使うか判断しなければならないし、そんなケースは結構存在する。
現れるエクストラな選択肢
PowerShell Seleniumモジュールを使用することを選んだ場合、エクストラな選択肢として、PowerShell Seleniumモジュールをcloneして自分で独自に開発を行うという方法もある。
PowerShell Seleniumモジュールは、MITライセンスの下で開発されている。メンテナンスを引き継ぐほどの負担は負えないとしても、自分が欲しい機能を実装したり、バグを修正したりするのはやぶさかではない、という方は多いはずだ。元がMITライセンスだから、自分が書き換えた部分もMITライセンス扱いにして、オープンソースで公開するというのも良いだろう。今のソフトウエア開発者は、オープンソースにさんざんお世話になっているはずなので、時にはほかのユーザーに貢献するというのも悪くない。
業界の健全な成長のためにも、良い“循環”を生み出していきたいところだ。
選んだのは「PowerShell Seleniumバージョン4.0.0-preview3」
本連載では、「PowerShell Seleniumバージョン4.0.0-preview3を使う」方法を選んだ。現在開発が止まっているので、実質的にこれが最後のバージョンになる可能性が高い。ただし、次のメリットが期待できる。
- Install-Moduleコマンドレットでインストールできる
- コマンドレットが整理されており、バーンジョン3系よりもスマートなスクリプトが書ける
逆に、次の点は苦労を伴う。
- ドキュメントが存在しないため、使い方を自分で見つけたり、ソースコードを読んで調べたりする必要がある。
多くのユーザーにとって、ドキュメントが存在しないことは致命的なので、通常は「バージョン3.0.1」を選ぶだろう。しかし、本連載では「ドキュメントの存在しないモジュールの使い方をどうやって調べて使うか」という点についても紹介していきたい。そうした意図から、4.0.0-preview3を選択したということもある。
特別なケースではなく、日常の風景
重要なのは、必要なライブラリやモジュールが何年もメンテナンスされていなかったり、使いたい機能のアップデートが行われていない点が懸念されたり、というのは特別なケースではなく、オープンソースソフトウエアにおいてはよくある話、ということである。
これはいろんなところで遭遇する事態だ。
今時、ソフトウエアを全て1から開発するというのは、やや現実離れした話だ。既存のソフトウエアを活用しないと、現実的なタイムラインで開発が終わらないだろう。ただし、使いたいソフトウエアが必ずしも、継続的にメンテナンスされているとは限らない。すでにある程度完成したライブラリ類は、放置されていることが多いのだ。そうしたライブラリは、最新の技術に対応できてなかったり、セキュリティ脆弱性が修正されていなかったりする。これが実情だ。
場合によっては、使いたいライブラリを自分で書き換える必要がある。そうなるとライセンスも含めて可否を検討し、選択を行う必要がある。オープンソースソフトウエアの活用は、こうした選択の連続でもある。
これはPowerShellも同じだ。モジュールの開発が必ずしも続いているとは限らない。場合によっては自分で開発を引き継ぎ、次のメンテナーにならなければならないことだってあるかもしれない。繰り返すが、これは珍しいことではなく、日常的に起こっていることなのだ。