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

вчера я узнал о новом инструменте Haskell под названием стек. На первый взгляд кажется, что он выполняет ту же работу, что и Кабал. Так в чем же разница между ними? Стек-замена кабалу? В каких случаях я должен использовать Stack вместо Cabal? Что может сделать стек, чего не может Кабал?

61
cabal haskell haskell-stack

3 ответов

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

да и нет.

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

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

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

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

есть хороший пост в блоге, объясняя разницу: почему стек не Кабал?

40

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

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

  • стек, С другой стороны, сначала посмотри ).

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

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

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

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

15

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

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

5