昨日、私はHaskellの新しいツールについて知りました。スタック一見すると、Cabal とほぼ同じ機能を果たすように見えます。では、これらの違いは何でしょうか? stack は Cabal の代わりとなるのでしょうか? どのような場合に Cabal ではなく Stack を使用すべきでしょうか? Stack でできて Cabal ではできないことは何でしょうか?
ベストアンサー1
スタックは Cabal の代替になりますか?
はいといいえ。
どのような場合に Cabal の代わりに Stack を使用すべきですか? Cabal ではできないが Stack ではできることは何ですか?
Stackは、キュレーションされたスタックパッケージを使用します。デフォルト. そうであれば、依存関係は一緒にビルドされることが分かっており、バージョン競合の問題 (Haskell の経験では一般的だった頃は「cabal hell」と呼ばれていました) を回避できます。Cabal の最近のバージョンには、競合を防ぐための対策も用意されています。それでも、リポジトリから取得される内容を正確に把握した、再現可能なビルド構成を設定することは、Stack を使用するとより簡単です。stackage 以外のパッケージを使用するための準備もあるため、stackage スナップショットにパッケージが存在しない場合でも問題なく使用できます。
個人的にはStackが好きで、Haskell開発者全員にStackの使用を勧めたい。彼らの開発は速いそして、多くのより良い UX。そして、Cabal がまだ提供していないが Stack が提供しているものがあります。
- Stack は GHC をダウンロードし、隔離された場所に保存します。
- Docker サポート (Haskell アプリケーションのデプロイに非常に便利です)
- 再現可能なHaskellスクリプト: パッケージのバージョンを正確に特定でき、問題なく常に実行されることが保証されます。(カバルにはスクリプト機能もあるただし、再現性を完全に保証するのはそれほど簡単ではありません。
- を実行する機能
stack build --fast --file-watch。存在するローカル ファイルを変更すると、自動的に再構築されます。--pedanticオプションと一緒に使用すると、私にとっては致命的です。 - Stackは、以下を使用してプロジェクトの作成をサポートします。テンプレート独自のカスタム テンプレートもサポートします。
- スタックには組み込みhパックサポートされています。これは、業界でより広く使用されている yaml ファイルを使用して cabal ファイルを作成するための代替 (私見では、より優れた) 方法を提供します。
- Interoはスムーズな体験を提供しますスタックを使用する場合。
違いを説明している素晴らしいブログ記事があります:Stack は Cabal ではないのはなぜですか?Cabal は、その投稿から数年の間に、そこで議論された問題のいくつかを克服するように進化しましたが、Stack の背後にある設計目標と哲学に関する議論は依然として重要です。