W dalszej części będę odnosił się do tych dwóch narzędzi, które są porównywane jako instalacja i układanie w stos . W szczególności użyję instalacji cabal, aby uniknąć pomyłki z biblioteką Cabal , która jest wspólną infrastrukturą używaną przez oba narzędzia.
Mówiąc ogólnie, możemy powiedzieć, że instalacja i stos cabal są nakładkami na wersję Cabal . Oba narzędzia umożliwiają budowanie projektów Haskell, których zestawy zależności mogą ze sobą kolidować w ramach jednego systemu. Kluczowa różnica między nimi polega na tym, jak realizują ten cel:
Domyślnie cabal-install , gdy zostaniesz poproszony o zbudowanie projektu, przyjrzy się zależnościom określonym w swoim .cabalpliku i użyje narzędzia do rozwiązywania zależności, aby znaleźć zestaw pakietów i wersji pakietów, które go spełniają. Ten zestaw pochodzi z całości Hackage - wszystkich pakietów i wszystkich wersji, przeszłych i obecnych. Po znalezieniu wykonalnego planu kompilacji wybrana wersja zależności zostanie zainstalowana i zindeksowana w bazie danych gdzieś w ~/.cabal. Konflikty wersji między zależnościami są unikane przez indeksowanie zainstalowanych pakietów zgodnie z ich wersjami (a także innymi odpowiednimi opcjami konfiguracji), dzięki czemu różne projekty mogą pobierać wersje zależności, których potrzebują, bez wchodzenia na siebie nawzajem. Ten układ jest tym, coDokumentacja instalacji cabal oznacza „lokalne kompilacje w stylu Nix” .
Kiedy zostaniesz poproszony o zbudowanie projektu, stack zamiast iść do Hackage, przyjrzy się resolverpolu stack.yaml. W domyślnym przepływie pracy to pole określa migawkę stosu , która jest podzbiorem pakietów Hackage ze stałymi wersjami, o których wiadomo, że są wzajemnie kompatybilne. stos spróbuje spełnić zależności określone w pliku (lub ewentualnie z pliku - inny format, sama rola) przy użyciu tylko to, co jest przez migawkę. Pakiety instalowane z każdej migawki są rejestrowane w oddzielnych bazach danych, które nie kolidują ze sobą..cabalproject.yaml
Można powiedzieć, że podejście oparte na stosie zamienia pewną elastyczność konfiguracji na prostotę, jeśli chodzi o określanie konfiguracji kompilacji. W szczególności, jeśli wiesz, że twój projekt używa, powiedzmy, migawki LTS 15.3, możesz przejść do jego strony Stackage i na pierwszy rzut oka dowiedzieć się, jakie wersje dowolnego stosu zależności mogą pobrać ze Stackage. To powiedziawszy, oba narzędzia oferują funkcje wykraczające poza podstawowe przepływy pracy, dzięki czemu, ogólnie rzecz biorąc, każde z nich może robić wszystko, co robi drugie (choć prawdopodobnie w mniej wygodny sposób). Na przykład istnieją sposoby na zamrożenie dokładnych wersji znanej dobrej konfiguracji kompilacji i rozwiązanie zależności ze starym stanem Hackage za pomocą cabal-installi możliwe jest wymaganie zależności innych niż stosy lub przesłanianie wersji pakietu migawek podczas korzystania ze stosu .
Na koniec kolejną różnicą między instalacją cabal a stosem, która jest na tyle duża, że warto o niej wspomnieć w tym przeglądzie, jest to, że stos ma na celu zapewnienie kompletnego środowiska kompilacji z funkcjami takimi jak automatyczne zarządzanie instalacją GHC i integracja z Dockerem . W przeciwieństwie do tego instalacja cabal ma być ortogonalna w stosunku do innych części ekosystemu, więc nie próbuje zapewniać tego rodzaju funkcji (w szczególności wersje GHC muszą być instalowane i zarządzane osobno, czy to za pośrednictwem dystrybucji Linuksa pakiety, Haskell Platform Core w systemie Windows lub narzędzie ghcup ).
cabal-installi wykorzystuje stackage tak bardzo, jak to możliwe - w pewnym momencie może wystąpić pewna integracja wsteczna z instalacją cabal i myślę, że społeczność nie jest pewna, czy jest to dobra rzecz, czy nie, ponieważ może to podzielić społeczność)