Jaka jest różnica między Cabal i Stack?

Wczoraj dowiedziałem się o nowym narzędziu Haskell o nazwie Stack . Na pierwszy rzut oka wygląda na to, że robi to samo, co Cabal. Jaka jest więc różnica między nimi? Czy stos zastępuje Cabal? W jakich przypadkach powinienem używać Stack zamiast Cabal? Co może zrobić Stack, czego Cabal nie może?

Czy stos zastępuje Cabal?

Tak i nie.

W jakich przypadkach powinienem używać Stack zamiast Cabal? Co może zrobić Stack, czego Cabal nie może?

Stack domyślnie używa wyselekcjonowanych pakietów stosu . W związku z tym wszelkie zależności są znane ze wspólnego budowania, unikając problemów z konfliktami wersji (które, gdy były powszechne w doświadczeniu Haskella, były znane jako „piekło kabały”). Najnowsze wersje Cabal również mają środki zapobiegające konfliktom. Mimo to skonfigurowanie odtwarzalnej konfiguracji kompilacji, w której dokładnie wiesz, co zostanie pobrane z repozytoriów, jest prostsze w przypadku stosu. Zauważ, że istnieje również możliwość korzystania z pakietów innych niż stosy, więc możesz iść, nawet jeśli pakietu nie ma w migawce stosu.

Osobiście lubię Stack i poleciłbym każdemu deweloperowi Haskell jego używanie. Ich rozwój jest szybki . I ma znacznie lepszy UX. Są rzeczy, które robi Stack, a których Cabal jeszcze nie zapewnia:

• Stack nawet pobiera GHC i utrzymuje go w odizolowanym miejscu.
• Obsługa Dockera (co jest bardzo wygodne przy wdrażaniu aplikacji Haskell)
• Powtarzalny skrypt Haskella : Możesz wskazać wersję pakietu i uzyskać gwarancję, że zawsze będzie wykonywany bez żadnych problemów. ( Cabal ma również funkcję skryptu , ale pełne zapewnienie odtwarzalności z nim nie jest tak proste.)
• Umiejętność stack build --fast --file-watch. Spowoduje to automatyczne odbudowanie, jeśli zmienisz obecne pliki lokalne. Używanie go razem z --pedanticopcją jest dla mnie przełomem.
• Stack obsługuje tworzenie projektów przy użyciu szablonów . Obsługuje również własne niestandardowe szablony.
• Stos ma wbudowaną obsługę hpack . Zapewnia alternatywny (IMO, lepszy) sposób pisania plików cabal przy użyciu pliku yaml, który jest szerzej używany w branży.
• Intero ma płynne doświadczenie podczas pracy ze Stackiem .

Jest fajny wpis na blogu wyjaśniający różnicę: Dlaczego Stack nie jest Cabal? Chociaż Cabal, w ciągu ostatnich lat od tego postu, ewoluował, aby przezwyciężyć niektóre z omawianych tam problemów, dyskusja na temat celów projektowych i filozofii stojącej za Stackiem pozostaje aktualna.

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 ).

Z tego, co mogę wyciągnąć z FAQ, wydaje się, że Stack używa biblioteki Cabal, ale nie cabal.exebinarnej (bardziej poprawnie znanej jako instalacja cabal). Wygląda na to, że celem projektu jest automatyczna piaskownica i uniknięcie piekła zależności.

Innymi słowy, używa tej samej struktury pakietu Cabal, po prostu zapewnia inny interfejs do zarządzania tymi rzeczami. (Myślę!)