cafegale(LeafCage備忘録)

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

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

notation

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

追記：nodejs(npm)の補完がmsys2のzshで動いてくれない（というかMingw の bashでしか動いてくれない）ので、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\currentとscoop\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側にインストールした言語からwindowsのGUIを開発することができた。100%互換性があるかどうかは不明。
  • nodejsがサポートされなくなった（削除された）
  • pacman の構文が気に入らない。
WSL
  • windows側のPATHを通す必要がない（コマンドプロンプト等からでもwsl rubyでrubyを呼べる）→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にはこういう未来が見えていたのだろうか。

Consider

C言語関係のコンパイル環境は MinGW32/64 を使うか、さもなくば MSVC(Microsoft Visual C++)を使う必要がある（そしてどうもMSVCはVS command prompt から実行しないと動かないそうだ）。こういうことを鑑みると、Windows上で動くC言語系をコンパイルする環境のみ、MinGW32/64 で構築しておくのも一案だ。とはいえWSLのパスにWindowsの$PATHを加える方針でやっていると思わぬ競合が生じそうで怖い（WSLローカルの環境がPATHの前の方に来るとは言え）。まぁ少なくとも、Windowsネイティブで（例えばscoopなどで）makeが提供されるようなことは今後しばらくも起こらないだろうということで、C環境については割り切ってMinGWを使うのもいい。
今のところとりあえず別にmsys2環境を分けて、そちらだけにMinGWの環境を立てているが。

ちなみに msys2/mingw にC環境を構築するコマンドは以下

$ pacman -S base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain

MSYS2 による gcc 開発環境の構築 ― gcc パッケージ群の導入 | text.Baldanders.info
パッケージグループなので、実際は結構な量のパッケージがインストールされる（pacman -Sg ＜パッケージグループ名＞ でどんなパッケージが含まれているか確認できる）。