Cabal과 Stack의 차이점은 무엇입니까?

어제 저는 Stack 이라는 새로운 Haskell 도구에 대해 배웠습니다 . 첫 번째 홍당무에서, 그것은 Cabal과 거의 같은 일을하는 것처럼 보입니다. 그렇다면 그들 사이의 차이점은 무엇입니까? 스택은 Cabal을 대체합니까? 어떤 경우에 Cabal 대신 Stack을 사용해야합니까? 기갑 단이 할 수없는 스택은 무엇을 할 수 있습니까?

스택은 Cabal을 대체합니까?

예 그리고 아니오.

어떤 경우에 Cabal 대신 Stack을 사용해야합니까? 기갑 단이 할 수없는 스택은 무엇을 할 수 있습니까?

Stack은 기본적으로 선별 된 스택 패키지를 사용합니다 . 그렇기 때문에 모든 종속성이 함께 빌드되어 버전 충돌 문제를 방지하는 것으로 알려져 있습니다 (예전에는 "카발 지옥"으로 알려 졌던 Haskell 환경에서 흔히 발생했던 문제). 최신 버전의 Cabal에는 충돌을 방지하기위한 조치가 마련되어 있습니다. 그래도 저장소에서 가져올 항목을 정확히 알고있는 재현 가능한 빌드 구성을 설정하는 것은 Stack을 사용하면 더 간단합니다. 스택이 아닌 패키지를 사용하기위한 프로비저닝도 있으므로 스택 스냅 샷에 패키지가없는 경우에도 사용하는 것이 좋습니다.

개인적으로 저는 Stack을 좋아하고 모든 Haskell 개발자에게 Stack을 사용하도록 권장합니다. 그들의 개발은 빠르다 . 그리고 훨씬 더 나은 UX를 가지고 있습니다. 그리고 Cabal이 아직 제공하지 않는 Stack이하는 일들이 있습니다 :

• Stack은 GHC를 다운로드하여 격리 된 위치에 보관합니다.
• Docker 지원 (Haskell 애플리케이션 배포에 매우 편리함)
• 재현 가능한 Haskell 스크립트 : 패키지 버전을 정확히 찾아 낼 수 있으며 항상 문제없이 실행된다는 보장을받을 수 있습니다. ( Cabal에는 스크립트 기능 도 있지만 이를 통해 재현성을 완벽하게 보장하는 것은 그리 간단하지 않습니다.)
• 할 수있는 능력 stack build --fast --file-watch. 존재하는 로컬 파일을 변경하면 자동으로 다시 빌드됩니다. --pedantic옵션 과 함께 사용하는 것은 저에게 거래 차단기입니다.
• Stack은 템플릿을 사용한 프로젝트 생성을 지원합니다 . 또한 사용자 지정 템플릿도 지원합니다.
• Stack에는 내장 된 hpack 지원이 있습니다. 업계에서 더 널리 사용되는 yaml 파일을 사용하여 cabal 파일을 작성하는 대안 (IMO, 더 나은) 방법을 제공합니다.
• Intero는 Stack으로 작업 할 때 부드러운 경험을 가지고 있습니다.

차이점을 설명하는 멋진 블로그 게시물 이 있습니다. Stack이 Cabal이 아닌 이유는 무엇입니까? Cabal은 그 포스트 이후 몇 년 동안 거기에서 논의 된 문제 중 일부를 극복하기 위해 발전했지만 Stack의 디자인 목표와 철학에 대한 논의는 여전히 관련이 있습니다.

다음에서는 cabal-install 및 stack 과 비교되는 두 도구를 참조합니다 . 특히 두 도구에서 사용하는 공통 인프라 인 Cabal 라이브러리 와의 혼동을 피하기 위해 cabal-install 을 사용합니다.

광범위하게 말하면 cabal-install 및 stack 은 Cabal의 . 두 도구 모두 단일 시스템의 범위 내에서 종속성 세트가 서로 충돌 할 수있는 Haskell 프로젝트를 빌드 할 수 있습니다. 이들 사이의 주요 차이점은이 목표를 달성하는 방법에 있습니다.

• 기본적으로 cabal-install 은 프로젝트 빌드를 요청하면 파일에 지정된 종속성을 확인하고 종속성 해결 프로그램을 사용하여이를 충족하는 패키지 및 패키지 버전 집합을 파악합니다. 이 세트는 전체적으로 Hackage 에서 가져온 것입니다. 모든 패키지와 모든 버전, 과거 및 현재. 실행 가능한 빌드 계획이 발견되면 선택한 종속성 버전이 .NET의 데이터베이스에 설치되고 인덱싱됩니다 . 버전 (및 기타 관련 구성 옵션)에 따라 설치된 패키지를 인덱싱하여 종속성 간의 버전 충돌을 피할 수 있으므로 서로 다른 프로젝트가 서로의 발걸음을 밟지 않고도 필요한 종속성 버전을 검색 할 수 있습니다. 이 배열은 무엇입니까cabal-install 설명서는 "Nix 스타일 로컬 빌드"를 의미 합니다..cabal~/.cabal 합니다.

• 프로젝트 구축을 물었을 때 스택 이 아니라 Hackage는 보는 것보다, 의지 resolver의 필드 stack.yaml. 기본 워크 플로우에서 해당 필드는 지정 Stackage의 스냅 샷 과 Hackage 패키지의 하위 집합입니다, 고정 상호 호환되는 것으로 알려져있다 버전. 스택은 다음에 지정된 종속성을 만족시키기 위해 시도합니다 .cabal파일 (아마도 또는 파일 스냅 샷에 의해 제공되는 것만을 사용하여 - 다른 형식으로, 같은 역할을). 각 스냅 샷에서 설치된 패키지는 서로 간섭하지 않는 별도의 데이터베이스에 등록됩니다.project.yaml

스택 접근 방식은 빌드 구성을 지정할 때 간단 함을 위해 약간의 설정 유연성을 제공 한다고 말할 수 있습니다. 특히 프로젝트에서 LTS 15.3 스냅 샷을 사용한다는 것을 알고 있다면 Stackage 페이지 로 이동하여 종속성 스택 의 버전을 한 눈에 알 수 있습니다. 에서 가져올 수 수 있습니다. 즉, 두 도구 모두 기본 워크 플로를 뛰어 넘는 기능을 제공하므로 대체로 각각 다른 도구가 수행하는 모든 작업을 수행 할 수 있습니다 (편의성이 떨어질 수 있음). 예를 들어, 알려진 양호한 빌드 구성의 정확한 버전 을 고정 하고 cabal -install을 사용하여 이전 상태의 Hackage 로 종속성 을 해결하는 방법이 있습니다.그리고 stack 을 사용하는 동안 비 Stackage 종속성 을 요구하거나 스냅 샷 패키지 버전 을 재정의 할 수 있습니다 .

마지막으로, 또 다른 차이점 음모 설치 및 스택 이 개요에서 언급 할 가치가 큰만큼 그되어있는 스택 과 같은 기능을 가진 완전한 빌드 환경을 제공하는 것을 목적으로 자동 GHC 설치 관리 및 도커 통합 . 반대로, cabal-install 은 생태계의 다른 부분과 직각을 이루는 것을 의미하므로 이런 종류의 기능을 제공하려고하지 않습니다 (특히 GHC 버전은 Linux 배포판을 통해 설치 되든 별도로 설치하고 관리해야합니다). 패키지, Windows 의 Haskell Platform Core 또는 ghcup 도구 ).

FAQ에서 얻을 수있는 바에 따르면 Stack은 Cabal 라이브러리를 사용하지만 cabal.exe 바이너리 (cabal-install로 더 정확하게 알려짐). 프로젝트의 목표는 자동 샌드 박싱과 의존성 지옥 회피 인 것 같습니다.

즉, 동일한 Cabal 패키지 구조를 사용하고이 항목을 관리하기위한 다른 프런트 엔드를 제공합니다. (나는 생각한다!)