Haskell · build · outillage

Stack vs Cabal : choisir un outil de build Haskell

Une fois un compilateur Haskell installé, il vous faut un moyen de gérer les dépendances et de construire votre projet. En 2026, il y a deux choix grand public : Cabal et Stack. Ils font le même travail de fond — récupérer les bibliothèques, construire votre code, lancer les tests — mais font des arbitrages différents quant à la provenance des paquets et au degré de reproductibilité des builds. Ce guide explique ce qu’est chacun, en quoi ils diffèrent, les commandes équivalentes, et comment choisir.

Ce qu’est Cabal

Cabal est le système de build original de Haskell. Le terme recouvre deux choses : la bibliothèque/spécification Cabal (le format de fichier .cabal qui décrit un paquet) et cabal-install, l’outil en ligne de commande cabal qui construit les paquets et résout les dépendances. Par défaut il récupère les bibliothèques depuis Hackage, l’archive centrale des paquets Haskell.

Le Cabal moderne utilise les builds locaux façon nix (les anciennes commandes v2-, désormais par défaut), qui donnent à chaque projet un build isolé et un store global partagé de paquets construits. Un solveur de dépendances choisit les versions qui satisfont les bornes que vous déclarez :

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

L’opérateur caret ^>= signifie « au moins cette version, mais n’autorise que les versions ultérieures compatibles ». Les réglages à l’échelle du projet vivent dans un fichier cabal.project. C’est la chaîne d’outils la plus étroitement alignée sur les releases de GHC et Hackage.

Ce qu’est Stack

Stack est un outil de build conçu autour de la reproductibilité. Au lieu de résoudre les versions contre tout Hackage, il construit contre un snapshot Stackage : un ensemble curé de versions de paquets connues pour compiler ensemble. Vous épinglez un snapshot dans stack.yaml :

resolver: lts-22.14
packages:
  - .

Parce que le snapshot fixe chaque version, quiconque récupère votre projet et lance stack build obtient les mêmes versions de dépendances — et Stack installera automatiquement le GHC correspondant à ce snapshot. Cette garantie « ça marche pareil partout » est l’attrait principal de Stack, surtout pour les équipes et la CI.

Les différences clés

• Source des paquets — Cabal résout contre tout Hackage ; Stack construit contre un snapshot Stackage curé. Stackage troque un peu de fraîcheur contre des ensembles garantis compatibles.
• Reproductibilité — Stack épingle tout via le snapshot par défaut. Cabal peut être tout aussi reproductible avec un fichier cabal.project.freeze, mais vous l’activez explicitement.
• Gestion de GHC — Stack télécharge et gère la version de GHC dont un snapshot a besoin. Avec Cabal, vous apportez votre propre GHC (couramment installé via GHCup).
• Fichiers de config — les deux lisent le fichier .cabal du paquet. Stack ajoute stack.yaml ; Cabal ajoute cabal.project.
• Alignement écosystème — Cabal suit de près les releases de GHC et Hackage ; Stack avance au rythme de la curation des snapshots.

Les commandes équivalentes

Au quotidien, les deux se ressemblent :

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

Les deux pilotent le même compilateur en dessous — voyez le guide GHC pour les options qui comptent. Notez que le Cabal d’aujourd’hui descend du workflow introduit dans Cabal 2.0, qui a remplacé l’ancienne approche des sandboxes.

Lequel choisir ?

En 2026, les deux sont bons et activement maintenus — ce n’est pas un cas où l’un est obsolète. Une règle de pouce raisonnable :

• Choisissez Cabal si vous voulez la chaîne d’outils par défaut alignée sur GHC, les dernières versions de paquets depuis Hackage, et un contrôle fin sur les bornes de versions. C’est le chemin que présument la plupart des nouveaux tutoriels.
• Choisissez Stack si vous valorisez la reproductibilité clé en main et la gestion automatique de GHC, ou si vous êtes dans une équipe où « tout le monde obtient le même build » compte plus que d’avoir les versions de bibliothèques les plus récentes.

Vous n’avez pas à décider pour toujours : GHCup installe les deux, et de nombreux projets livrent un stack.yaml et un cabal.project pour que les contributeurs puissent utiliser l’un ou l’autre. Essayez-en un, et changez si ses arbitrages ne conviennent pas.

FAQ

Cabal ou Stack, lequel est meilleur ? Aucun n’est strictement meilleur ; ils optimisent pour des choses différentes. Cabal privilégie les versions Hackage à jour et l’alignement étroit sur GHC ; Stack privilégie des snapshots curés et reproductibles et l’installation automatique de GHC.

Stack et Cabal utilisent-ils le même format de paquet ? Oui. Les deux lisent le fichier .cabal du paquet. Stack ajoute stack.yaml par-dessus ; Cabal ajoute cabal.project.

Qu’est-ce qu’un snapshot Stackage ? Un ensemble curé de versions de paquets Hackage vérifiées pour compiler ensemble, identifié par un resolver comme lts-22.14. En épingler un rend les builds reproductibles.

Puis-je passer de Stack à Cabal plus tard ? Généralement oui — le fichier .cabal est partagé, donc vous ajoutez surtout un cabal.project et fournissez un GHC (via GHCup). Les bornes de versions peuvent demander un petit nettoyage.

Nouveau dans la chaîne d’outils ? Commencez par installer Haskell avec GHCup, qui met en place GHC, Cabal et Stack ensemble.