Далее я буду ссылаться на два сравниваемых инструмента: cabal-install и stack . В частности, я буду использовать cabal-install, чтобы избежать путаницы с библиотекой Cabal , которая является общей инфраструктурой, используемой обоими инструментами.
В общих чертах, мы можем сказать, что cabal-install и stack - это фронтенды Cabal . Оба инструмента позволяют создавать проекты Haskell, наборы зависимостей которых могут конфликтовать друг с другом в рамках одной системы. Ключевое различие между ними заключается в том, как они достигают этой цели:
По умолчанию, при запросе на сборку проекта cabal-install проверяет зависимости, указанные в его .cabalфайле, и использует решатель зависимостей для определения набора пакетов и версий пакетов, которые ему удовлетворяют. Этот набор взят из Hackage в целом - все пакеты и все версии, прошлые и настоящие. Как только осуществимый план сборки будет найден, выбранная версия зависимостей будет установлена и проиндексирована в базе данных где-нибудь в ~/.cabal. Конфликтов версий между зависимостями можно избежать за счет индексации установленных пакетов в соответствии с их версиями (а также другими соответствующими параметрами конфигурации), чтобы разные проекты могли получать нужные им версии зависимостей, не наступая друг другу на пятки. Это то, чтоДокументация по установке cabal означает "локальные сборки в стиле Nix" .
Когда вас попросят создать проект, стек будет смотреть не на Hackage, а на resolverполе stack.yaml. В рабочем процессе по умолчанию в этом поле указывается моментальный снимок стека , который является подмножеством пакетов Hackage с фиксированными версиями, которые, как известно, являются взаимно совместимыми. стек попытается удовлетворить зависимости, указанные в .cabalфайле (или, возможно, в project.yamlфайле - другой формат, та же роль), используя только то, что предоставлено моментальным снимком. Пакеты, устанавливаемые из каждого снимка, регистрируются в отдельных базах данных, которые не мешают друг другу.
Можно сказать, что стековый подход предлагает некоторую гибкость настройки ради простоты, когда дело доходит до указания конфигурации сборки. В частности, если вы знаете, что ваш проект использует, скажем, моментальный снимок LTS 15.3, вы можете перейти на его страницу Stackage и сразу узнать, что версии любого стека зависимостей могут быть извлечены из Stackage. Тем не менее, оба инструмента предлагают функции, которые выходят за рамки основных рабочих процессов, так что, по большому счету, каждый может делать все, что делает другой (хотя, возможно, менее удобным способом). Например, есть способы заморозить точные версии заведомо хорошей конфигурации сборки и решить зависимости со старым состоянием Hackage с помощью cabal -install , и можно потребовать зависимости, не относящиеся к стеку, или переопределить версии пакетов моментальных снимков при использовании стека .
Наконец, еще одно различие между cabal-install и стеком, которое достаточно велико, чтобы его стоит упомянуть в этом обзоре, заключается в том, что стек нацелен на предоставление полной среды сборки с такими функциями, как автоматическое управление установкой GHC и интеграция с Docker . В отличие от этого, cabal-install должен быть ортогонален другим частям экосистемы, и поэтому он не пытается предоставлять такую функцию (в частности, версии GHC должны устанавливаться и управляться отдельно, будь то через дистрибутив Linux. пакеты, ядро платформы Haskell в Windows или инструмент ghcup ).
cabal-installи использует стек в максимально возможной степени - в какой-то момент может произойти некоторая обратная интеграция с cabal-install, и я думаю сообщество не уверено, хорошо это или нет, потому что это может разделить сообщество)