2023-07-29 追記。現時点ではWSL2はだいぶ進化しているので、以下の記事はもう古い。WSL2上でのChromeもテスト用途としては十分機能する。WSLgのインストールも簡単。WSL2でいい。
VisualStudoio Codeを使ってると何かとWSL2をおすすめされる。WSL2で課題とされていたことが解決したのかと思ったがどうもそうでもなさそう。WSL1を便利に使っていたので全体的に怒り口調で書いています。
以下、課題を挙げる。
いまだにlocalhostが共有できない（あたり前だけど）
これは仮想マシンを立ち上げた時の昔からある課題。Windows→WSLへのlocalhostは回避策があるが、WSL→Windowsへのlocalhostはアクセスできない。WSL1に比べて大幅な機能ダウン。
「WSLがサーバーでWindowsがクライアントだからそれでいいんじゃない？」って思う人もいるかも知れないが、Windows側がサーバーになることもある。例えばSeleniumなんかがそう。SeleniumにしてもChrome DevTools Protocol にしても、Windows側がlocalhostでlistenする。「WSL2はSeleniumを始めとするブラウザオートメーションが使えない」という今どきのWeb開発には致命的な不便さがある。
回避策としては、WSL2側にChromeをインストールすればいい。WSL2側でGUIまで立ち上げればもはやUbuntu完結だ。でももはやそれは「Windowsを使わない」と同義。VSCodeもChromeも全部Ubuntuでやりたかったら、最初からUbuntuをブートすりゃぁいい。普段使いのChromeをUbuntu上のプログラムから自動化してこそ「PCを自動化した」といえる。
WSL2が本流だと思ってた被害者がここにもいる。
https://neos21.hatenablog.com/entry/2020/10/13/080000#Selenium-Webdriver-%E3%81%AF%E5%87%BA%E6%9D%A5%E3%81%9D%E3%81%86%E3%81%A7%E5%87%BA%E6%9D%A5%E3%81%AA%E3%81%8B%E3%81%A3%E3%81%9F
当然のことがなら、WSL2からWindows側のlocalhostでlistenしてるseleniumドライバは見えない。かわいそうに。毛布をかけてあげたい。
今どきのプロセス間通信はlocalhostのIP通信が基本なんだから、localhostが互いに共有できてない時点でもはや「一つのPC」で開発している意味なんてない。それを「Windows Subsystem」と名前をつけるので誤解を生む。素直に「軽量VM」って言えばいい。
当然のことながらWindowsのファイルシステムへのアクセスはWSL1が速い
WSL2は速いけど、Windowsへのファイルアクセスは遅いんだ、それは我慢してね。って話だが、それもWSLの目的をわかってない。マイクロソフト自身がWSLの目的を理解してない。WSL上でバッチを回すってのは、Chromeを自動操縦したり、ffmpegで動画を変換したり、imagemagickで静止画を変換したいからやってること。WindowsのGUIで見るものを、Ubuntu上のCUIで一括操作をしたいからこそのWSL。Ubuntu完結なら最初からLinuxマシン使ってる。
マイクロソフトはWSL2ではファイルの共有がいまいちだってことの回避策としてこんなことを言ってる。
いやいや、VS Code ってソースコードを編集するためのものであって、動画見たり静止画みたりするもんじゃないよね。Windowsでユーザが何をしているかが全然わかってない。
VS CodeはたしかにRemote開発がめちゃくちゃ便利だ。なんならWSLみたいな手元の環境だけじゃなくて、ガチのリモートサーバーでさえもローカルで開発しているかのように開発できる。
じゃもうクラウドサーバー上で開発しちゃえばいい。クラウドサーバー上のファイルは直接みれない、クラウドサーバー上でselenium動かしてもブラウザが動いてるところが見れない、だからWSL1はありがたかったのに、WSL2はその意義を消し去ってる。
改めてWindows周辺を自動化したい
バッチファイルでもなく、PowerShellでもなく、Linux上で育成されたオープンソースプロダクトを使って、Windows側を自動化したいというニーズに「どん」とハマっていたのはWSL1なのでした。だから尊い。
ステージング環境は開発環境とは別
とはいえWSL1が純正Linuxではないというところはデメリットではある。Dockerが使えないとかそういうところ。ただDockerは開発を楽にするためのものと言うよりも、デプロイを楽にするための仕組み。開発環境とステージング環境を同一視するのに無理がある。手元でプロトタイプを作るのに、Rubyのバージョンのコンセンサスなんて要らない。MySQLでもMariaDBでもどっちでもいい。サクラエディタでコードを触るということだってあっていい。Windowsファイルシステム上でWinMergeを使っている人に、それは時代遅れだという気もしない。WindowsのGUIアプリもそれなりに便利なものがあって、それはすべて「開発時に」「お勉強するときに」便利なもの。当然Web開発のステージング環境ではWindows要素はゼロになるが、そんなのわかってる。
Windowsの豊富なGUIツールとLinuxの豊富なCUIツールのいいとこどりをさせてほしい。WSLは「Better Cygwin」でいい。