cafegale(LeafCage備忘録)

LeafCage備忘録(はてなダイアリー)と統一しました。

windowsでMSYS2とWSLとネイティブインストールの使い分け

windows上での開発環境について、かつてはmsys2とそれに付随しているmingwですべてを賄おうとしていたが、msys2/mingwでnodejsがサポート外になったことと、ネイティブでしかサポートしていないアプリや開発環境が増えたこと、そもそもネイティブのPATHにmsys2やmingwのPATHを通すのは間違いのような気がしてきたので、これからの使い分けについて考えてみる。
あと不用意にパソコンを初期化してしまってローカルにあった設定とかわからなくなったし。

追記:nodejs(npm)の補完がmsys2のzshで動いてくれない(というかMingwbashでしか動いてくれない)ので、zshの上でnpm使う計画は頓挫した。
completion: refused to run under CYGWIN bash · Issue #13624 · npm/npm
yarn なら大丈夫のようだ。

Windowsネイティブ

安定していて互換性あることは保証されるが代償としてレジストリやPATHが汚されていく。

  • PATHを通さなければいけない欠点はscoopに任せるのでおおよそ解消される。
    • 単体のアプリなら、scoop\shimsに追加されていくからPATHが無尽蔵に増えていくことはなさそうだが、それでもときにscoopが勝手にPATHを追加していくことはある。例えばnodejsを入れたらscoop\apps\nodejs\currentscoop\apps\nodejs\current\binを追加された。
  • レジストリを汚す可能性がある。scoopに任せてもレジストリは汚れていくんだろうか?
  • GUIを開発するならネイティブにインストールするしかない?
  • scoopでは使用可能なものが少なく、windowsネイティブでも使用できないツールがある(rbenvなど)。
MSYS2

ネイティブで使えないUnix系のツール(zshとかtmuxとか)を使うときに頼りにする。

  • コマンドプロンプト等から呼ぶときにはPATHを通す必要がある。
  • windows側のPATHを汚したくないなら同梱されているランチャ(msys2.exe, mingw32.exe, mingw64.exe)から起動するのが基本になる。
  • なぜか内部にmsys2とmingwのエリアが分かれてあって、本格的に開発言語をインストールするときにはmingw側にインストールしないと不具合が出る(msys側は言語バージョンが低かったりするんだっけ?それともサポートされてる言語が少なかったんだっけ?忘れたけど)
    • mingw側を使いたい場合はmsys2.exeではなくmingw32.exe, mingw64.exeから起動しなければいけない(そうしないとmingw側のPATHが通らない)。
  • mingw側にインストールした言語からwindowsGUIを開発することができた。100%互換性があるかどうかは不明。
  • nodejsがサポートされなくなった(削除された)
  • pacman の構文が気に入らない。
WSL
  • windows側のPATHを通す必要がない(コマンドプロンプト等からでもwsl rubyrubyを呼べる)→PATHが汚くわけわからなくなるのを防げる
  • (おそらく)GUIを扱えないと思う。

欲求

  • なるべくネイティブのPATHやレジストリを汚すような真似はしたくない。
  • ネイティブのPATHにmsys2のPATHを通すのをやめたい。ネイティブのPATHは勝手に足されて自分で設定したものがわからなくなってくるし、意図せずunix系統のコマンドが呼ばれるのはよくないのではないか。

以上を踏まえての方針

  • msys2のシェルをメインに使う。MSYS2_PATH_TYPEをinheritにしてwindows環境変数を受け継ぎ、主にscoopで入れたネイティブプログラムも実行できるようにする。
  • msys2はmingwを使わずmsys2側だけ使い、役割はツールの提供だけの最低構成にする。
  • 実行環境の提供はWSLに任せ、wslコマンドで呼び出すようにする。
  • wslで動かない状況が発生したとき、scoopでインストールし、ネイティブで実行する。
  • *nix環境で動かすときにはwsl付き、ネイティブで動かすときにはwslなしと、動作環境を明瞭にする。

これまでmsys2のmingwに実行環境を作っていたのをWSLに役割を移す。msys2内のmingwの立ち位置が中途半端だったし、プログラムがmsys側にあるのかmingw側にあるのか気にしたくなかった。

調べたところMSYS2も、自己完結して動くアプリ(エディタやファイラなど)はmsys2側で提供し、実際のプログラミング言語の提供はmingw側に任せmsys2は関知しない方針を貫いているようで、つまりはmingwの代わりにWSLを使っても何の問題もない。
MSYS2にはこういう未来が見えていたのだろうか。