haskell-jp / random #98 at 2022-05-12 14:18:36 +0900

VS Code の Haskell 拡張が HLS の管理をしてくれなくなったので ghcman にも HLS 管理機能を入れたい

VSCode の Haskell extension のバージョンを上げて、手許に ghcup を入れて設定しなおせば、ツールチェインも含めて管理してくれるようになりますが、これではだめですか？

HLS の自動インストールには、GHC のバージョンとOS, arch の組合せ（そのハッシュ）を適切に管理する必要があったり、GHC 9.0.2 のようなイレギュラーな場合ビルドリビジョンに起因する ABI の違いなども吸収する必要があって（ここはまだ対応できてないですが）、結構デリケートなところがあるので、GHCup と HLS のチームは連携して作業を進めていたりします。

VS Code 拡張くんは ghc-os-arch からどの HLS を使うかを ghcup 使って解決してるってことですかね
ふーむ

どちらかというと ghcup にその辺りの判別まで任せて自動で入れるようにさせている、という形ですね。設定によっては、HLS だけでなく stack のインストールとかも ghcup 経由でしてくれるようになってます。

cabal ベースだったら GHC のインストールとかも自動でやってくれるんじゃなかったかな（初期設定でどこまでやってくれたかはちょっと覚えていないです

動機としては、ふだん UNIX ツールチェーンを使ってない＆ghcup が Windows 非対応のころから自前管理してたという経緯で GHC がすでにマシンにあるのに ghcup 使うと別途インストールされるので、なんかやだなーという気持ちでした

なるほどー。stack とか使ってればそっちの ghc を使ってくれるので重複はないんですけど、自前管理だとちょっとつらそうですね。個人用途なら完全に決め打ちで持ってきてしまうとか、ghcup のリリース情報の YAML の情報だけ拝借して、そっからインストールするロジックは自前で書く（or ghcup から port する）とかがいいのかもしれません

ghcup の作者の Julian はかなり密に ghc / HLS のチームと連絡をとりあっている（何せ ghcup は公式推奨のインストール方法になっているので）ので、その成果物のリリース情報のハッシュ値はけっこう信頼していいと思います

ただ 9,0.2 は profile build まわりが欠けていて一部環境向けでは二回リリースが行われている都合上、ちょっとトリッキーなのでどのバイナリを使っているのかはちゃんと考慮する必要があったりしますが

ghcup の metadata 群はここにあるみたいですね https://github.com/haskell/ghcup-metadata

なんかポロっと書いただけなのに知見助かります

9.0.2、バッドノウハウすぎる……