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

Question

Вчера я узнал о новом инструменте Haskell под названием Stack. При первом румянце похоже, что он выполняет ту же работу, что и Cabal. Итак, в чем разница между ними? Является ли стек заменой для Cabal? В каких случаях я должен использовать Stack вместо Cabal? Что может сделать Stack, что Cabal не может?

Answer 1

Укладывать замену для Cabal?

Да и №

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

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

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

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

Существует хороший блог объяснить разницу: Why is Stack not Cabal?

Answer 2

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

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

Answer 3

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

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

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

Имейте в виду, что приведенное выше описание охватывает рабочие процессы по умолчанию для каждого инструмента. Большая часть того, что может сделать стек, может быть выполнена в некотором (возможно, менее удобном) порядке с 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-style local builds добавляется в междусобойчик установить как альтернативный способ смягчения конфликтов версий, которая является потенциально более удобным, чем cabal sandbox. Эта функция доступна в виде предварительного просмотра от cabal-install 1.24.