WSLgで開発環境を割とガチめに整えてみた

# なぜまたこんなことを？

僕はコード書くときにほぼJetbrainsの各製品に下駄を預けた状態になっている。加えてメインの環境がWindowsなので、当然jetbrainsのWindows版を使ってきた。

ただし、今般使ってみると、[Windows: Couldn't Run with Coverage for separate test.](https://youtrack.jetbrains.com/issue/RUST-17139/Windows-Couldnt-Run-with-Coverage-for-separate-test.)　とか、[WebStorm runnning on the windows can't display the vitest's success/failure marker in the code pain](https://youtrack.jetbrains.com/issue/WEB-71783/WebStorm-runnning-on-the-windows-cant-display-the-vitests-success-failure-marker-in-the-code-pain)などのWindows固有の問題が主にテスト方面に散見されて、結構ストレスを感じていた。Ubuntu（というかLinux）で実行すればこれらの問題が発生しないことを確認できたので、それじゃLinux環境で実行してみようと結構試行錯誤してみた。だけどいまいちしっくりこなかった。

### SSH Remote

悪くはないのだけど、Github copilotとかJetbrains AIのSuggestがうまく機能しなくてあえなく断念。加えてClient/Hostでの環境の調停が結構面倒だった

### 実機

隣に転がってるUbuntuを使ってRDP経由でリモートデスクトップを用いてみた。

RDPの方にWinキーが食われるなど些末な問題はあったけどこれは比較的うまく動かすことができた。けれど、本務機（Windows)よりも非力だったのでどうせだったら本務機側のマシンパワー使いたいなぁという個人的な欲求があったのでいったん没案に

### WSLg

シームレスにいくにはこれが一番かなぁと思う反面、環境構築がくっそ面倒だなぁと思っていた（じっさいくっっっっっっっっそ面倒だった）

ただ稼働させたらそこそこうまくいったので現在使用中＆この環境構築の沼にはまった顛末記が今回の主題



# 今回考慮しないことと、注意事項

さて、以下のセクションから実際にjetbrains toolbox経由で各製品の起動とおまけでgitkraken、そしてcredential通すのに必要なのでGoogle chromeの導入を図った顛末記になる。

さて、先に説明しておくと、**WSLgでホスト側のIMEを使うことができないという割と致命的な問題が存在する**。おそらくMozcなどを別途導入することでWSLg環境でも日本語を通すことができると思うけど、ATOKのキーバインドになれてる＆他のIME使うとキーバインドたとえ合わせてもなんかこれじゃない感があって実際あんまり使いやすくないし、日本語書くような作業はWindows環境で行うつもりなのでここは今回バッサリ諦めた。逆にここが致命的という方はMozcを入れるかそもそもこの環境構築をあんまりおすすめできないかなって思う。

また、WSLgはそれなりに**メモリを食う**ので、その辺もご注意のほど



# 利用環境

今回の利用環境は以下の通り

* Windows11 24H2 
* WSL2
  * Ubuntu24.04 LTS



尚、vhdxが深いところにあると面倒なので、[**WSLにrootfsからUbuntuをインストール**](https://zenn.dev/dozo/articles/a633794f6d7575) を参考にStore経由ではないインストールを行っている。従って以下の説明はStore経由のインストール環境でも動かせるかどうか検証していないのでご注意のほど



## 事前準備

[Linux GUI アプリのインストール サポート](https://learn.microsoft.com/ja-jp/windows/wsl/tutorials/gui-apps#install-support-for-linux-gui-apps)にあるとおり、vGPUのサポートが必須なので、対応するドライバを当てておこう。次にWSL2の上で稼働させる必要があるので、

``` 
wsl ｰｰupdate
wsl --shutdown
```

を実行して、WSL2へ移行しておこう


## 各種導入



### gnome-keychain & seahorse

jetbrainsの各製品はUser secretを不揮発に管理するために、Native keychainを利用するか、KeePassファイルの利用のどちらかを必要としている。Native keychainでもし運用したいのなら、gnome-keyringと、必要に応じて補助的にseahorseを導入しておく。



![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/9662/7d696663-a718-4f77-92cd-cf1911fdb596.png)




``` 
sudo apt install gnome-keyring seahorse;
```



### 日本語フォント

入力を求めないとはいえ、日本語が出てこないのは不便なのでフォントは用意しておく。ここではaptで導入可能なfonts-noto-cjkを導入している

```
sudo apt install fonts-noto-cjk
```



### Google chrome

当然HostのWindowsにも何らかのWebBrowserは入っているのでそっちを使っても良いのだけど、連携などでCredentialの確認を行う際、起動してこないことがあるのでWSLgの上にも何らかのWeb browserを導入しておいた方が何かと便利だった。

[導入方法](https://learn.microsoft.com/ja-jp/windows/wsl/tutorials/gui-apps#install-google-chrome-for-linux)を参考にして必要なら入れておく。



### jetbrains toolbox

ようやくこれでtoolboxの導入までこぎ着けた。先に導入したWebBrowserで[toolbox](https://www.jetbrains.com/toolbox-app/)にアクセスして、tar ballを取得後、解凍して実行する。

ここで、fuseが必要だと怒られた場合は、Issueに従って導入しておく



### gitkraken

[gitkraken](https://www.gitkraken.com/)にアクセスして、debファイルを落としておく。その後

```
sudo apt install --fix-missing <DLしてきたdeb>
```

を実行することでインストールできる



## 実行方法

ここまで準備がそろったら、実際に起動してみよう。Google chromeやGitkrakenはShellから直接叩いて実行してもかまわないけど、jetbrains toolboxは先に述べたCredential dataをNative keychainで管理している場合、gnome-keychainが利用可能な状態で実行する必要がある。ちゃんとしたデスクトップ環境のあるUbuntuなりであればデスクトップマネージャがその辺を引き受けてくれるのだけど、WSLgには残念ながらそのような機能がないので自分で構築するしかない。

[このへん](https://www.gitkraken.com/)を参考に環境を整えておこう。一例として僕の場合は以下のようになる。

```bash
dbus-run-session -- sh
printf "<Pass word>" | gnome-keyring-daemon --unlock
./jetbrains-toolbox

```

dbus を使っている関係上、僕の知識ではシェルスクリプトにすることができなかったので愚直に毎回叩いている。この辺のスクリプト化に対する知見をお持ちの方がいれば是非ご教授いただきたい次第。



## まとめと落ち穂拾い

これでおそらく､jetbrains toolboxが起動できるはずである。

起動後に必要なIDEを導入し、同様にCargo/dotnetなど必要なToolcainや環境を導入しておこう。

以下は数週間使ってみて気づいた点についてまとめておきたい

#### Github copilotに関して

Github copilotのCredentialがなかなか通らない事態に結構な確率で陥った。状況としては、Tokenを取得してページに飛んでAuthroizeしてSucessのPageが表示されてもIDE側でWaiting状態が続いてしまう。

Windows firewallを切ったりしたけどどれも奏功せず、唯一なんとなくこれかなぁと思うのはWi-Fiじゃなくて有線の方が成功率が高いということと、以前WSLg2使う.vhdxを外付けのSSD（結構遅い）に導入していたときより、M.2 SSDに入れていたほうが成功率がぐっと高まったのでとにかく安定した高速な環境で実行した方が良いのかなぁ程度しか解決策を持っていない



### Host側WindowsとのProject dirの共有

端的に言うと**絶対に**やめといた方が良い。ファイルの変更通知が飛んでこないので最新の状態に自動リロードされないし、Rustなんかの場合そもそも使うバイナリとかライブラリが何から何まで違うので何のうまみもない。

Githubなどを介した連携が一番シンプルでおすすめ。もし同一マシン内で同期をとりたい場合、Host os 側にMinGW+MSYS2を入れてrsyncあたりで同期すれば良いと思うけど同期ズレを起こすと目も当てられないのであんまりおすすめしない

### で、実際使ってみてどうよ？（ぽすとすくりぷと）
実行環境は人それぞれなので、あくまで僕の用途に対する僕の環境での主観的な使い心地ってことにはなるけど、存外悪くないというのが正直なところ。
IMEの切り替えが面倒なので、コードにマルチバイトを入れることはほぼないし、Copilot chatにも基本英語でといわせてるので個人的に日本語が通せないという部分に全く不便はなかった（というか複雑な文脈を含む場合はCopilot chatではなくてChatGPTの方に投げているから問うのもあるかも。）補足すれば質問の最後に`tell me as Japanese`とか打っとけば多分日本語にできる。（確実じゃない。駄目なら英文での解答後にas Japaneseとか売っとけば多分きっとうまくいく。

リソースに関しては、まぁ食いますわ。WSLが結構なMemory eaterだし、昨今のIDEはそれなりにメモリを食うのでここはもう諦めてもらうしかないかなと思った。

逆に、PythonやLangC形のToolchainをaptで管理できたり、RustRover/CLionの場合、Profierが使える、また先に述べたようなWindowsでしか発生しない問題は完全に解決したので使いやすくはなった。

仕込みは大変だし、リソースは結構食うので万人受けする環境構築じゃないとは思うけど、**イラッ**としたことが解消できたので､個人的にはやってよかったし、この先もこれでひとまず使ってみようかなと思っている。