Яка різниця між Кабалом і Стек?

Вчора я дізнався про новий інструмент Haskell під назвою Stack . При перших рум'янах схоже, що це робить таку ж роботу, що і Кабал. Отже, в чому різниця між ними? Чи є стек заміною для Cabal? У яких випадках я повинен використовувати Stack замість Cabal? Що може Стек зробити, що Кабал не може?

Чи є стек заміною для Cabal?

Так і ні.

У яких випадках слід використовувати Stack замість Cabal? Що може Стек зробити, що Кабал не може?

За замовчуванням стек використовує куративні пакети стеків . При цьому будь-які залежності, як відомо, будують разом, уникаючи конфліктних версій (які, коли вони були звичними в досвіді Haskell, раніше називали "пекельним пеклам"). Останні версії Cabal також мають заходи щодо запобігання конфлікту. Однак налаштування відтворюваної конфігурації збірки, в якій ви точно знаєте, що буде витягнуто з сховищ, є більш простим для Stack. Зауважте, що також передбачено використання пакетів, що не містять стека, так що ви можете пройти навіть у тому випадку, якщо пакета немає в знімку стеки.

Особисто мені подобається Stack і рекомендую всім розробникам Haskell використовувати його. Їх розвиток відбувається швидко . І він має набагато кращий UX. І є речі, які робить Стек, які Кабал ще не надає:

• Стек навіть завантажує GHC для вас і зберігає його в ізольованому місці.
• Підтримка Docker (що дуже зручно для розгортання ваших програм Haskell)
• Відтворюваний сценарій Haskell : Ви можете точно визначити версію пакета та отримати гарантію, що він завжди буде виконуватися без будь-яких проблем. (У Кабала також є особливість сценарію , але повністю забезпечити відтворюваність з ним не зовсім просто.)
• Здатність робити stack build --fast --file-watch. Це автоматично відновиться, якщо ви зміните наявні локальні файли. Використання його разом із --pedanticопцією є для мене вимикачем угод.
• Стек підтримує створення проектів за допомогою шаблонів . Він також підтримує власні власні шаблони.
• Стек має вбудовану підтримку hpack . Він надає альтернативний (IMO, кращий) спосіб запису файлів кабалу за допомогою файлу yaml, який широко використовується в промисловості.
• Під час роботи зі Stack Intero має безперебійний досвід .

Є приємна публікація в блозі, що пояснює різницю: Чому Стек не Кабал? Хоча Кабал протягом наступних років після цієї посади еволюціонував, щоб подолати деякі обговорювані там питання, обговорення цілей дизайну та філософії, що лежать в основі Stack, залишається актуальним.

У подальшому я згадаю два інструменти, які порівнюються як встановлення та stabal . Зокрема, я буду використовувати cabal-install, щоб уникнути плутанини з бібліотекою Cabal , яка є загальною інфраструктурою, яка використовується обома інструментами.

Грубо кажучи, ми можемо сказати , міжсобойчик встановити і стека є інтерфейсами для змовників . Обидва інструменти дозволяють будувати проекти Haskell, набори залежностей яких можуть конфліктувати між собою в межах єдиної системи. Ключова різниця між ними полягає в тому, як вони вирішують цю мету:

• За замовчуванням cabal-install , коли його запитуватимуть створити проект, перегляне залежності, визначені у його .cabalфайлі, та використає вирішувач залежності, щоб визначити набір пакунків та версій пакетів, які його задовольняють. Цей набір взято з Hackage в цілому - всі пакунки та всі версії, минулі та сучасні. Як тільки буде здійснено реальний план збірки, обрана версія залежностей буде встановлена ​​та індексована в базі даних десь у ~/.cabal. Конфліктів версій між залежностями можна уникнути шляхом індексації встановлених пакетів відповідно до їх версій (а також інших відповідних параметрів конфігурації), так що різні проекти можуть отримувати потрібні версії залежностей, не наступаючи один на одного. Це домовленістьДокументація встановити cabal означає "локальні побудови в стилі Nix" .

• На запит створити проект, стек буде замість того, щоб їхати в Hackage, шукати resolverполе stack.yaml. У робочому процесі за замовчуванням це поле вказує знімок стека , який є підмножиною пакетів Hackage з фіксованими версіями, які, як відомо, є сумісними. стек буде намагатися задовольнити залежності , зазначені в файлі (або , можливо , в файл - інший формат, ту ж роль) , використовуючи тільки те , що забезпечується моментальний знімок. Пакети, встановлені з кожного знімка, реєструються в окремих базах даних, які не заважають один одному..cabalproject.yaml

Можна сказати, що підхід до стеку обробляє деяку гнучкість у налаштуванні для прямолінійності, коли мова йде про визначення конфігурації збірки. Зокрема, якщо ви знаєте, що ваш проект використовує, скажімо, знімок LTS 15.3, ви можете перейти на його сторінку стека і знати, на перший погляд, версії будь-якого стека залежностей, які можуть витягуватися із стека. Однак, обидва інструменти пропонують функції, що виходять за рамки базових робочих процесів, так що, за великим рахунком, кожен може робити все, що робить інший (хоча можливо і менш зручним способом). Наприклад, є способи заморозити точні версії відомої гарної конфігурації збірки та вирішити залежності зі старим станом Hackage за допомогою cabal -install, і під час використання стека можна зажадати залежностей, що не укладаються, або змінити версії пакетних знімків .

Нарешті, ще одна відмінність між встановленням кабала та стеком, яка є достатньо великою, що варто згадати в цьому огляді, полягає в тому, що стек має на меті забезпечити повне середовище побудови з такими функціями, як автоматичне управління встановленням GHC та інтеграція Докера . На відміну від цього, програма cabal встановлюється як ортогональна для інших частин екосистеми, і тому вона не намагається надати такий тип функції (зокрема, версії GHC повинні встановлюватися та керуватися окремо, будь то через Linux Linux пакети, ядро Haskell Platform в Windows або інструмент ghcup ).

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

Іншими словами, він використовує ту саму структуру пакету Cabal, він просто забезпечує інший фронт-енд для управління цим матеріалом. (Я думаю!)