Haskell · build · strumenti

Stack vs Cabal: scegliere uno strumento di build Haskell

Una volta installato un compilatore Haskell, ti serve un modo per gestire le dipendenze e costruire il tuo progetto. Nel 2026 ci sono due scelte mainstream: Cabal e Stack. Fanno lo stesso lavoro di fondo — recuperare le librerie, costruire il tuo codice, eseguire i test — ma fanno compromessi diversi su dove provengono i pacchetti e su quanto sono riproducibili le build. Questa guida spiega cosa sono, in cosa differiscono, i comandi equivalenti e come scegliere.

Cos’è Cabal

Cabal è il sistema di build originale di Haskell. Il termine copre due cose: la libreria/specifica Cabal (il formato di file .cabal che descrive un pacchetto) e cabal-install, lo strumento a riga di comando cabal che costruisce i pacchetti e risolve le dipendenze. Per impostazione predefinita recupera le librerie da Hackage, l’archivio centrale dei pacchetti Haskell.

Il Cabal moderno usa le build locali in stile nix (i precedenti comandi v2-, ora predefiniti), che danno a ogni progetto una build isolata e uno store globale condiviso di pacchetti costruiti. Un risolutore di dipendenze sceglie le versioni che soddisfano i vincoli che dichiari:

-- in your .cabal file
build-depends: base >=4.14 && <5, text, aeson ^>=2.1

L’operatore caret ^>= significa « almeno questa versione, ma consenti solo le versioni successive compatibili ». Le impostazioni a livello di progetto vivono in un file cabal.project. È la toolchain più strettamente allineata alle release di GHC e Hackage.

Cos’è Stack

Stack è uno strumento di build progettato attorno alla riproducibilità. Invece di risolvere le versioni contro tutto Hackage, costruisce contro uno snapshot Stackage: un insieme curato di versioni di pacchetti note per compilare insieme. Fissi uno snapshot in stack.yaml:

resolver: lts-22.14
packages:
  - .

Poiché lo snapshot fissa ogni versione, chiunque recuperi il tuo progetto ed esegua stack build ottiene le stesse versioni di dipendenze — e Stack installerà automaticamente il GHC corrispondente a quello snapshot. Questa garanzia « funziona uguale ovunque » è l’attrattiva principale di Stack, soprattutto per i team e la CI.

Le differenze chiave

• Fonte dei pacchetti — Cabal risolve contro tutto Hackage; Stack costruisce contro uno snapshot Stackage curato. Stackage baratta un po’ di freschezza con insiemi garantiti compatibili.
• Riproducibilità — Stack fissa tutto tramite lo snapshot per impostazione predefinita. Cabal può essere altrettanto riproducibile con un file cabal.project.freeze, ma lo attivi esplicitamente.
• Gestione di GHC — Stack scarica e gestisce la versione di GHC di cui uno snapshot ha bisogno. Con Cabal, porti il tuo GHC (comunemente installato tramite GHCup).
• File di configurazione — entrambi leggono il file .cabal del pacchetto. Stack aggiunge stack.yaml; Cabal aggiunge cabal.project.
• Allineamento all’ecosistema — Cabal segue da vicino le release di GHC e Hackage; Stack avanza al ritmo della curazione degli snapshot.

I comandi equivalenti

Nel quotidiano, i due si somigliano:

-- Cabal                  -- Stack
cabal build               stack build
cabal run myapp           stack run
cabal test                stack test
cabal repl                stack ghci
cabal haddock             stack haddock

Entrambi pilotano lo stesso compilatore sotto — vedi la guida a GHC per le opzioni che contano. Nota che il Cabal di oggi discende dal workflow introdotto in Cabal 2.0, che ha sostituito il vecchio approccio delle sandbox.

Quale scegliere?

Nel 2026 entrambi sono buoni e attivamente mantenuti — non è un caso in cui uno è obsoleto. Una regola pratica ragionevole:

• Scegli Cabal se vuoi la toolchain predefinita allineata a GHC, le ultime versioni di pacchetti da Hackage e un controllo fine sui vincoli di versione. È il percorso che la maggior parte dei nuovi tutorial presuppone.
• Scegli Stack se apprezzi la riproducibilità chiavi in mano e la gestione automatica di GHC, o se sei in un team dove « tutti ottengono la stessa build » conta più dell’avere le versioni di librerie più recenti.

Non devi decidere per sempre: GHCup installa entrambi, e molti progetti includono uno stack.yaml e un cabal.project così che i contributori possano usare l’uno o l’altro. Provane uno, e cambia se i suoi compromessi non ti convincono.

FAQ

Cabal o Stack, quale è migliore? Nessuno è strettamente migliore; ottimizzano per cose diverse. Cabal privilegia le versioni Hackage aggiornate e l’allineamento stretto a GHC; Stack privilegia snapshot curati e riproducibili e l’installazione automatica di GHC.

Stack e Cabal usano lo stesso formato di pacchetto? Sì. Entrambi leggono il file .cabal del pacchetto. Stack aggiunge stack.yaml sopra; Cabal aggiunge cabal.project.

Cos’è uno snapshot Stackage? Un insieme curato di versioni di pacchetti Hackage verificate per compilare insieme, identificato da un resolver come lts-22.14. Fissarne uno rende le build riproducibili.

Posso passare da Stack a Cabal più tardi? Generalmente sì — il file .cabal è condiviso, quindi aggiungi soprattutto un cabal.project e fornisci un GHC (tramite GHCup). I vincoli di versione possono richiedere una piccola pulizia.

Nuovo alla toolchain? Inizia da installare Haskell con GHCup, che configura GHC, Cabal e Stack insieme.