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

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

---

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

---

스택은 Cabal을 대체합니까?

예 그리고 아니오.

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

기본적으로Stack 선별 된 스택 패키지를 사용 하므로 패키지가 함께 빌드되는 것으로 알려져 있습니다. 기갑 단에서는 기갑 단 지옥에 맞을 가능성이 있습니다. 스택은 또한 로컬로 패키지를 캐시하므로 다음에 해당 패키지 (또는 전 이적 종속성)를 사용할 때 처음부터 모든 것을 컴파일하지 않습니다. 스택이 아닌 패키지를 사용하기위한 프로비저닝도 있으므로 스택 스냅 샷에 패키지가없는 경우에도 사용하는 것이 좋습니다.

개인적으로 저는 Stack을 좋아하고 모든 Haskell 개발자에게 Stack을 사용하도록 권장합니다. 그들의 개발은 빠르다 . 그들은 이전 버전과의 호환성에 대해 (그다지) 걱정하지 않습니다. 그리고 훨씬 더 나은 UX를 가지고 있습니다. 그리고 가지가 stack않습니다 Cabal제공하지 않습니다 아직은 :

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

차이점을 설명하는 멋진 블로그 게시물 이 있습니다. Stack이 Cabal이 아닌 이유는 무엇입니까?

---

다음에서는 cabal-install 및 stack 과 비교되는 두 도구를 참조합니다 . 특히 두 도구에서 사용하는 공통 인프라 인 Cabal 라이브러리 와의 혼동을 피하기 위해 cabal-install 을 사용합니다. 광범위하게 말하면 cabal-install 과 stack 이 Cabal의 프런트 엔드 라고 말할 수 있으며 , 이들 간의 주요 차이점은 기본 워크 플로가 무엇인지로 귀결됩니다.

• 기본적으로 cabal-install 은 프로젝트 빌드를 요청하면 해당 .cabal파일에 지정된 종속성을 확인하고 종속성 해결 프로그램을 사용하여 (가능한 경우)이를 충족하는 패키지 및 패키지 버전 집합을 파악합니다. 이 세트는 전체적으로 Hackage 에서 가져온 것입니다. 모든 패키지와 모든 버전, 과거 및 현재. 실행 가능한 빌드 계획이 발견되면 선택한 종속성 버전이 기본적으로 설치된 패키지의 단일 데이터베이스에 설치되고 등록됩니다 ~/.cabal.

• 반면 stack 은 먼저 resolver필드를 stack.yaml봅니다. 이 필드는 일반적 으로 상호 호환되는 것으로 알려진 고정 버전이있는 Hackage 패키지의 하위 집합 인 Stackage 스냅 샷을 지정합니다 . 그러면 스택 은 기본적으로 스냅 샷에서 제공하는 것만 사용하여 종속성을 충족 시키려고 시도합니다. 하나의 스냅 샷에서 설치된 패키지는 서로 다른 격리 된 데이터베이스에 등록되며 스냅 샷에 필요한 사항을 설명하기 위해 별도의 GHC 설치가 유지됩니다. 이 접근 방식은 설치된 패키지간에 버전 비 호환성이 없다는 보장으로 약간의 유연성을 제공합니다 (단일 패키지 데이터베이스를 사용할 때 일반적인 문제).cabal-install , 이 기사 에서 논의한 이유 )뿐만 아니라 프로젝트를 빌드하는 데 사용할 정확한 종속성 버전을 항상 파악할 수 있습니다 (완전한 프로젝트의 재현 가능한 빌드를 보장하는 데 유용하고 .hs동반 .cabal파일 없이 자체 포함 된 스크립트의 종속성을 쉽게 지정하기 위해 ).

위의 설명은 각 도구의 기본 워크 플로를 다룹니다. 스택 이 수행 할 수있는 대부분의 작업은 기본값에서 벗어나 cabal-install을 사용 하여 다소 덜 편리한 방식으로 달성 할 수 있으며 그 반대의 경우도 마찬가지입니다. 특히:

• cabal-install 은 cabal sandbox명령을 통해 각 프로젝트에 대해 격리 된 패키지 데이터베이스를 지원 하지만 스택 및 Stackage 스냅 샷과 달리 프로젝트간에 설치된 패키지를 공유 할 가능성이 없습니다. 를 .cabal통해 독립적으로 빌드에 사용할 종속성 버전을 수정하는 것도 가능합니다 cabal freeze. ( cabal-install 아날로그가 없는 관련 스택 기능 중 하나 는 별도의 GHC 설치 관리입니다 .)stack setup

• 스택 프로젝트에 적절한 필드 설정에 의해 사용되는 스냅 숏 Stackage에서 사용할 수없는 패키지를 사용할 수 있습니다 stack.yaml( extra-depsStackage에서 Hackage에서 사용할 수 있지만 패키지를, 그리고 packages정의와 location하지 Hackage에서 패키지). 이러한 비 Stackage 패키지는 스냅 샷과 격리 된 상태로 프로젝트별로 설치됩니다. stack solverHackage (예 : 비 Stackage) 종속성에 대한 자동 종속성 해결을 수행 하는 명령 도 있습니다 .

On a final note, it is worth mentioning that support for Nix-style local builds is being added to cabal-install as an alternative way of mitigating version conflicts which is potentially more convenient than cabal sandbox. This feature is available, as a preview release, from cabal-install 1.24.

---

From what I can glean from the FAQ, it seems that Stack uses the Cabal library, but not the cabal.exe binary (more correctly known as cabal-install). It looks like the aim of the project is automatic sandboxing and avoidance of dependency hell.

In other words, it uses the same Cabal package structure, it just provides a different front-end for managing this stuff. (I think!)

참고URL : https://stackoverflow.com/questions/30913145/what-is-the-difference-between-cabal-and-stack