В чем разница между Cabal и Stack?

Ответ 1

Является ли стек заменой для Cabal?

Да и Нет.

В каких случаях я должен использовать Stack вместо Cabal? Что может сделать Stack в том, что Cabal не может?

Так как Stack по умолчанию использует кураторские пакеты стека, пакеты, как известно, собираются вместе. В Кабале есть шанс, что вы можете попасть в адский ад. Стек также локально кэширует ваш пакет, так что вы не скомпилируете все с нуля, когда будете использовать этот пакет (или его транзитивную зависимость) в следующий раз. Обратите внимание, что также предусмотрена возможность использования пакетов non stackage, поэтому вы можете пойти, даже если пакет отсутствует в снимке стопки.

Лично мне нравится Stack. Их развитие происходит быстро. Они не беспокоятся (что много) о обратной совместимости. И он имеет более сильный лучший UX. И есть вещи, которые Stack делает, что Cabal пока не предоставляет:

• Стеки даже загружают GHC для вас и хранят его в изолированном месте.
• Поддержка докеров
• Воспроизводимый Haskell script: вы можете определить версию пакета и получить гарантию того, что он будет всегда выполняться без каких-либо проблем.
• Возможность сделать stack build --fast --file-watch. Это будет автоматически восстанавливаться, если вы измените локальные файлы. Использование его вместе с опцией --pedantic - это разблокировка сделки для меня.
• Возможность указать внешний репозиторий git в качестве зависимости.
• Stack поддерживает создание проектов с использованием templates.
• В стеке встроена поддержка hpack. Он предоставляет альтернативный способ (IMO, лучший) для написания файлов кабала.

Есть хорошая запись в блоге, объясняющая разницу: Почему Stack not Cabal?

Ответ 2

В дальнейшем я буду ссылаться на два инструмента, которые сравниваются, как установка и сборка. В частности, я буду использовать cabal-install, чтобы избежать путаницы с библиотекой Cabal, которая является общей инфраструктурой, используемой обоими инструментами. Вообще говоря, мы можем сказать, что cabal-install и stack являются интерфейсами к Cabal, а ключевые различия между ними сводятся к тому, что являются рабочими процессами по умолчанию:

• По умолчанию cabal-install при запросе создания проекта рассматривает зависимости, указанные в файле .cabal, и использует решатель зависимостей, чтобы выяснить (если возможно) набор пакетов и пакетов версии, которые его удовлетворяют. Этот набор сделан из Hackage в целом - все пакеты и все версии, прошлые и настоящие. После того, как будет найден возможный план сборки, выбранная версия зависимостей по умолчанию будет установлена ​​и зарегистрирована в одной базе данных установленных пакетов где-нибудь в ~/.cabal.

  С другой стороны, стек

• сначала рассмотрит поле resolver stack.yaml. В этом поле обычно указывается моментальный снимок Stackage, который является подмножеством пакетов Hackage с фиксированными версиями, которые, как известно, взаимно совместимы. стек будет по умолчанию пытаться удовлетворить зависимости, используя исключительно то, что предоставляется моментальным снимком. Пакеты, установленные из одного моментального снимка, регистрируются в разных и изолированных базах данных, а отдельные установки GHC поддерживаются для учета того, что требуют моментальные снимки. Этот подход мало управляет гарантией того, что не будет никакой несовместимости версий между установленными пакетами (общая проблема при использовании единой базы данных пакетов с помощью cabal-install по причинам, обсуждаемым в в этой статье), а также всегда можно определить точные версии зависимостей, которые будут использоваться для создания проекта (что полезно как для обеспечения воспроизводимых сборок полнофункциональных проектов, так и для легко определяя зависимости автономных сценариев .hs без файла-компаньона .cabal).

Помните, что приведенное выше описание охватывает рабочие процессы по умолчанию для каждого инструмента. Большая часть того, что может сделать стек, достижима в некоторых (возможно, менее удобных) манере с помощью cabal-install, выходя из стандартных значений, и наоборот. В частности:

• cabal-install поддерживает изолированные базы данных пакетов для каждого проекта с помощью команды cabal sandbox, хотя в отличие от снимков стека и Stackage нет возможности совместного использования установленных пакетов между проектами. Фиксирование версий зависимостей, которые будут использоваться для сборки независимо от .cabal, также возможно, через cabal freeze. (Одна связанная функция стека без аналога для установки в каббале - это управление отдельными установками GHC, т.е. stack setup.)

• проекты стека могут использовать пакеты, недоступные из моментального снимка Stackage, используемого путем установки соответствующих полей в stack.yaml (extra-deps для пакетов, доступных из Hackage, но не из Stackage, и packages с пользовательским location для пакетов, не входящих в Hackage). Эти пакеты не-Stackage устанавливаются на основе каждого проекта с отключением от снимков. Существует также команда stack solver, которая выполняет автоматическое решение зависимостей для зависимостей Hackage (то есть не-Stackage).

В заключение отметим, что поддержка локальных сборок Nix-стиля добавляется в cabal-install как альтернативный способ для смягчения конфликтов версий, что потенциально более удобно, чем cabal sandbox. Эта функция доступна, как предварительный выпуск, из cabal-install 1.24.

Ответ 3

Из того, что я могу извлечь из FAQ, кажется, что Stack использует библиотеку Cabal, но не двоичный код cabal.exe (более известный как cabal-install). Похоже, что целью проекта является автоматическая песочница и избегание адского образа.

Другими словами, он использует ту же структуру пакета Cabal, он просто предоставляет другой интерфейс для управления этим материалом. (Я думаю!)