Aşağıda, cabal-install ve stack olarak karşılaştırılan iki araca değineceğim . Özellikle, her iki araç tarafından da kullanılan ortak altyapı olan Cabal kitaplığıyla karışıklığı önlemek için cabal-install kullanacağım .
Geniş anlamda, diyebiliriz cabal yükleme ve istif etmek önyüzleridir Cabal'a . Her iki araç da, tek bir sistemin sınırları içinde bağımlılıkları birbiriyle çatışabilecek Haskell projeleri oluşturmayı mümkün kılar. Aralarındaki temel fark, bu hedefi nasıl ele aldıklarında yatmaktadır:
Varsayılan olarak, cabal-install , bir proje oluşturması istendiğinde, .cabaldosyasında belirtilen bağımlılıklara bakar ve onu karşılayan bir dizi paket ve paket sürümünü bulmak için bir bağımlılık çözücü kullanır. Bu set bir bütün olarak Hackage'dan alınmıştır - tüm paketler ve tüm sürümler, geçmiş ve şimdiki. Uygulanabilir bir yapı planı bulunduğunda, bağımlılıkların seçilen sürümü içinde bir yerde bir veritabanında kurulacak ve dizine eklenecektir ~/.cabal. Farklı projeler birbirlerinin ayak parmaklarına basmadan ihtiyaç duydukları bağımlılık sürümlerini alabilmeleri için, yüklenen paketlerin sürümlerine (ve diğer ilgili yapılandırma seçeneklerine) göre endekslenmesiyle bağımlılıklar arasındaki sürüm çakışmaları önlenir. Bu düzenleme necabal-install belgeleri "Nix tarzı yerel yapılar" anlamına gelir .
Bir proje oluşturmanız istendiğinde, Stack Hackage'a gitmek yerine resolveralanına bakacaktır stack.yaml. Varsayılan iş akışında bu alan , karşılıklı olarak uyumlu olduğu bilinen sabit sürümlere sahip Hackage paketlerinin bir alt kümesi olan bir Yığın anlık görüntüsünü belirtir . Yığın daha sonra belirtilen bağımlılıkları karşılamak için çalışacaktır dosyası (muhtemelen ya dosyayı anlık tarafından sağlanmaktadır yalnızca ne kullanarak - Farklı formatı, aynı rol). Her anlık görüntüden yüklenen paketler, birbirini engellemeyen ayrı veritabanlarına kaydedilir..cabalproject.yaml
Biz söylenebilir yığını bir yapı yapılandırma belirlemek söz konusu olduğunda yaklaşım dürüstlük için bazı kurulum esnekliği esnaf. Özellikle, projenizin örneğin LTS 15.3 anlık görüntüsünü kullandığını biliyorsanız, Stackage sayfasına gidebilir ve bir bakışta herhangi bir bağımlılık yığınının sürümlerinin Stackage'den çekilebileceğini anlayabilirsiniz. Bununla birlikte, her iki araç da temel iş akışlarının ötesine geçen özellikler sunar, böylece genel olarak her biri diğerinin yaptığı her şeyi yapabilir (muhtemelen daha az uygun bir şekilde). Örneğin, bilinen iyi bir yapı yapılandırmasının tam sürümlerini dondurmanın ve bağımlılıkları cabal-install ile eski bir Hackage durumuyla çözmenin yolları vardır.ve Stackage dışı bağımlılıkları zorunlu kılmak veya yığın kullanırken anlık görüntü paketi sürümlerini geçersiz kılmak mümkündür .
Son olarak, bu genel bakışta bahsetmeye değer kadar büyük olan cabal-install ile yığın arasındaki diğer bir fark , yığının otomatik GHC kurulum yönetimi ve Docker entegrasyonu gibi özelliklerle eksiksiz bir yapı ortamı sağlamayı amaçlamasıdır . Buna karşılık, cabal-install , ekosistemin diğer bölümlerine ortogonal olması amaçlanmıştır ve bu nedenle, bu tür bir özelliği sağlamaya çalışmaz (özellikle, GHC sürümleri, ister Linux dağıtımı yoluyla olsun, ayrı olarak kurulmalı ve yönetilmelidir paketleri, Windows'ta Haskell Platform Core veya ghcup aracı ).
cabal-install, olabildiğince yığın değiştirir ve kullanır - bir noktada cabal-install'a bir miktar geri entegrasyon olabilir ve bence Bu iyi bir şey olup olmadığını topluluk) o topluluğa bölünmüş olabileceğinden, emin değildir