stackTweet先日、我らがHaskellのデファクトスタンダードなコンパイラー、GHCのバージョン8.8.1-alpha1がリリースされました。このリリースはまだアルファ版であることからわかるとおり、主にテスト目的で使用するためのものです。試してみて、GHCのデバッグに貢献してみましょう。そこで今回は、最近Haskellを始めた方なら使っている方も多いであろう、stackを使ってこの新しいGHCをインストールし、あなたのライブラリー・アプリケーションでテストする方法を紹介いたします。--with-ghc=ghc-8.8.0.20190424などと実行した方がいいんじゃないかという気がしました...。cabal-installにはGHCをインストールする機能はないので、その場合はGHCは別途インストールすることになります(ghcupが使える?)。@takenobu-hsさんが書いてくれた、こちらの記事を参考にどうぞ!なお、stackでやると面倒な理由についての詳細はこれから述べる手順で適宜触れます...。setup-infoを作るまずはじめに、stackがGHCをインストールする際に参照する、setup-infoというYAMLを作りましょう。buildを実行したとき、GHCなどの必要なソフトウェアがインストールされていなかった際、自動でGHCをインストールするために必要な情報です。GHCのバージョンや対象となるプラットフォームごとに、GHCのビルド済みtarballへのURLやそのチェックサムが書いてあります。stackはここに書かれたURLにアクセスすることで、GHCをインストールしているんですね。デフォルトでは、stackはこちらのYAMLファイルをsetup-infoとして扱っています。Nightlyにもまだ採用されていないGHCについては、書かれていません。8.8.1-alpha1用のsetup-infoを作る必要があります。🙇)ひとまずみなさんは、下記のいずれかの方法で指定するだけでこの手順はクリアできます。8.8を試す用のディレクトリーを作って、そこに👆の内容が書かれたstack.yamlを置きましょう。https://gist.github.com/igrep/7298e1e2515059ae332feaf5501c41a4/raw/d69cc0b75d9be6735bdfcca6aa3eb6398d98983f/stack-setup-info.yaml--setup-info-yamlオプションを指定した上で8.8.0.20190424という引数を与えるのがポイントです。8.8.1-alpha1で試しにビルドしたいという方向けです。8.8.1-alpha1をちょっと試したいだけという方はこれ以降を読む必要はありません。trueを追記しましょう。これは、依存しているCabalパッケージのバージョンの、上限を取っ払うというものです。依存パッケージのバージョンの上限は、パッケージの開発者が自身のパッケージを確実にビルドできるよう、「このパッケージはあのパッケージのバージョンN.M以下じゃないとビルドできないよ!」とCabalの依存関係リゾルバーに教えてあげるためのものです。cabal-install(と、恐らくstackも必要に応じて)は、通常であればこの上限を見て、どのバージョンのパッケージをインストールするか決めます。その上限により、残念ながら依存関係の解決に失敗することがあるのです。trueと設定して、上限を無視してみましょう。いうのも、このバージョンの上限はしばしば、予防のために実際より厳しめに設定されることがあるためです1。今作っているパッケージが依存しているAPIが、どのバージョンで使用できなくなるかなんて、大抵のパッケージではわかりませんし。Versioningと似た思想のバージョン変更ポリシーがありまして、APIの互換性がなくなるような修正が含まれる場合、次のバージョンではA.B.CのA.Bの箇所を変更することになっています。これを信じて依存バージョンの上限(と下限)を設定してみても、実際にあなたが依存しているAPIが使用できなくなるとは限らないのです。したがって、依存パッケージのバージョンの上限は、実際には無視してもよい場合がしばしばあります。自分で依存パッケージのバージョンを正しく書き換えて対応するというのもアリですし、将来的にはそうした方がより望ましいやり方です。8.8とは関係のない原因でビルドが失敗する可能性がある点にも注意してください。trueを設定することと致しました。「私はバージョンの上限を直してみたいんだー!」という方は、是非チャレンジしてみてください。package-indicesを設定して、head.hackageを利用できるようにするstack.yamlに書いておいた方が良い設定がもう一つあります。それは、HEAD.hackageの設定です。これからビルドするあなたのパッケージは、きっとたくさんのパッケージに依存していることでしょう。8.8に対応できていないものも数多くあるでしょう😰。Proposalによる、Monad型クラスの仕様変更を適切に周知できていなかったこともあり、まだ多くのパッケージが対応できていないようです。requestを送っているかも知れません。ラッキーな場合、HEAD.hackageにパッチを当てたバージョンが上がっていることでしょう!HEAD.hackageは、今回のようにGHCの開発版をいち早く試したい人が、新しいGHCに向けて修正を加えたパッケージを、いち早くアップロードするサイトです。こちらのリポジトリーにパッチをアップロードすることで、cabal-installやstackから、普通のhackageにあるパッケージとしてダウンロードできるようにしてくれます。HEAD.hackageをstackで利用するには、下記のように、package-indices:という設定を、stack.yamlに加えてください。下記のように記載することで、stackは、HEAD.hackageにある修正済みのパッケージを優先して取得してくれるようになります2。--file-watchと、--file-watchオプションを付けて、stack.yamlを編集する度に再度ビルドが実行されるようにするのをおすすめします。言うのも、恐らく次👇のようなエラーがたくさん出ると思われるからです。protected]:d49e174ed0daecd059c52d13d4f4de87b5609c81212a22adbb92431f9cd58fff...このエラー、見かけたことがある人も多いでしょう。指定したresolver(stackが使用するパッケージのバージョンの一覧。Stackageに登録されているlts-13.12などもその一つ)に、必要なバージョンのパッケージが登録されていない場合に起こるエラーです。13.19で2346件。Stackageをメンテしている皆さんのおかげですね)。8.8に添付されたパッケージ(baseパッケージや、arrayパッケージなど)しか入っていない、実質空っぽなresolverなのです(参考)。そのため、あなたが必要なほとんどのパッケージはないため、stackはやむなく「extra-depsにこれらのパッケージを追加してね!」というエラーを出すことになります。これではstackの良さを生かせません...。new-freezeでもすれば、完全にビルドを再現可能な状態にしてくれます。stackはあくまでもStackageを活かすためのツールと捉えた方がいいのかも知れません😥。extra-depsへのパッケージの追記を何度か繰り返すと、ようやくパッケージのビルドが始まります。HEAD.hackageに収録されたパッケージを正しく取得できていれば、現在Hackageにアップロードされているバージョンではビルドできない依存パッケージも、無事ビルドできることでしょう。依存するパッケージの数にもよりますが、やっぱり時間がかかるかと思います。extra-depsを使い倒すしかしやっぱり、必要な変更が施されたパッケージが、HEAD.hackageにもアップロードされていない場合はあります。requestを送りつつ)パッチをHEAD.hackageのリポジトリーにアップロードすることもできますが、stack.yamlのextra-depsを次のように使えば、もっと手っ取り早く修正したバージョンのビルドを試すことができます。tohere自分以外の人が対象のパッケージを修正した場合:自分以外の人が対象のパッケージを修正したので、すでにどこかのリポジトリーにpush済みのコミットがある、という場合、下記👇のように書くと、Gitリポジトリーの特定のコミットを直接参照した状態で、依存関係に加えることができます。addして、自分のリポジトリーの一部に含めてしまいましょう。その上で、extra-depsには下記のように書けば、stackはローカルのファイルシステムに置かれたディレクトリーも、直接依存するパッケージとして追加してくれます。なんてのを繰り返していたら、面倒だからです。tohere対象のパッケージがGitリポジトリーで管理されてない場合は?臨機応変に対応しましょう...😰ちなみに、extra-depsのドキュメントいわくstackはMercurialもサポートしています。8.8-alpha1のインストール方法や、それを利用したパッケージのビルド手順です。自分でGHCをビルドしたときなども参考にしてみてください。8.8に関連して、非常に意欲的なプロジェクト💪を紹介させてください。Vanguardです。8.8に対応させる」プロジェクトです。Vanguardのリポジトリーを見ていて知りました💡。8.8に対応していないパッケージは恐らくまだたくさんあります。Securityの設定も必要なはずなんですが、なぜかうまくいかず...😱。こちらで紹介されたworkaroundにしたがって、関連する設定を除くことにしました...。@mizunashi-manaさん!)のですが、手元のパッケージでは依存関係を解決できず、エラーになってしまいました...。ライセンスの下に提供されています。Analyticsでアクセス情報を収集しています。集めた情報は統計的に処理した上で、当ウェブサイトの改善のための参考情報としてのみ使用します。