[解決済み] CabalとStackの違いは何ですか？

質問

昨日、Haskellの新しいツールである スタック . 一見したところ、Cabalとほとんど同じような仕事をしているように見える。では、両者の違いは何でしょうか？スタックはCabalの代わりになるのでしょうか？どのような場合にCabalの代わりにStackを使うべきですか？CabalにできなくてStackにできることは何ですか？

どのように解決するのですか？

スタックはCabalの代わりになるのか？

はい、そしていいえ。

どのような場合にCabalではなくStackを使うべきですか？CabalにできなくてStackにできることは何ですか？

Stack は、次のようなパッケージで構成されています。 デフォルト . そのため、依存関係があっても一緒にビルドされることが分かっており、バージョンの衝突問題（Haskellの経験では当たり前だったころは、"Cabal hell"として知られていた）を避けることができます。最近のCabalのバージョンでは、衝突を防ぐための対策も施されています。それでも、リポジトリから何が引き出されるかを正確に把握した上で再現性のあるビルド構成を設定するには、Stackの方がより簡単です。また、stackage 以外のパッケージも利用できるため、stackage のスナップショットにパッケージが存在しない場合でも問題ありません。

個人的に、私は Stack が好きで、すべての Haskell 開発者に使うことをお勧めします。彼らの開発は 速い . そして、それは も多く より良いUXです。そして、StackにはCabalがまだ提供していないものがあるのです。

• StackはGHCをダウンロードし、隔離された場所に保存することもできます。
• Dockerのサポート（Haskellアプリケーションのデプロイに非常に便利です。）
• 再現可能なHaskellスクリプト : パッケージのバージョンを特定し、常に問題なく実行できる保証を得ることができます。( Cabalにはスクリプト機能もあります。 がありますが、これによる再現性の完全な確保は、それほど簡単ではありません)。
• できること stack build --fast --file-watch . これは、存在するローカルファイルを変更した場合、自動的に再構築されます。と一緒に使うことで --pedantic オプションと一緒に使うことは、私にとっては破格のことです。
• Stack は テンプレート . また、独自のカスタムテンプレートもサポートしています。
• Stack は、組み込みの hpack をサポートしています。これは、業界でより広く使われている yaml ファイルを使用して、cabal ファイルを書く代替方法 (IMO, より良い) を提供します。
• Intero はスムーズなエクスペリエンスを提供します。 を使用する場合 .

違いを説明した素敵なブログ記事があります。 なぜStackはCabalではないのですか？ この投稿から数年の間に、Cabal はそこで議論された問題のいくつかを克服するように進化しましたが、Stack の背後にある設計目標と哲学の議論は依然として適切なままです。