Dans ce qui suit, je ferai référence aux deux outils comparés en tant que cabal-install et stack . En particulier, j'utiliserai cabal-install pour éviter toute confusion avec la bibliothèque Cabal , qui est une infrastructure commune utilisée par les deux outils.
De manière générale, nous pouvons dire que l' installation et la pile de la cabale sont des interfaces pour Cabal . Les deux outils permettent de construire des projets Haskell dont les ensembles de dépendances peuvent entrer en conflit les uns avec les autres dans les limites d'un seul système. La principale différence entre eux réside dans la manière dont ils abordent cet objectif:
Par défaut, cabal-install , lorsqu'on lui demande de construire un projet, examine les dépendances spécifiées dans son .cabal
fichier et utilise un solveur de dépendances pour déterminer un ensemble de packages et de versions de packages qui le satisfont. Cet ensemble est tiré de Hackage dans son ensemble - tous les packages et toutes les versions, passées et présentes. Une fois qu'un plan de construction réalisable est trouvé, la version choisie des dépendances sera installée et indexée dans une base de données quelque part dans ~/.cabal
. Les conflits de version entre les dépendances sont évités en indexant les packages installés en fonction de leurs versions (ainsi que d'autres options de configuration pertinentes), afin que différents projets puissent récupérer les versions de dépendances dont ils ont besoin sans se marcher sur les pieds. Cet arrangement est ce que lela documentation cabal-install signifie par "versions locales de style Nix" .
Lorsqu'on lui a demandé de créer un projet, stack , plutôt que d'aller dans Hackage, regardera le resolver
domaine de stack.yaml
. Dans le flux de travail par défaut, ce champ spécifie un instantané de Stackage , qui est un sous-ensemble de packages de piratage avec des versions fixes connues pour être compatibles entre elles. stack tentera alors de satisfaire les dépendances spécifiées dans le fichier (ou éventuellement le fichier - format différent, même rôle) en utilisant uniquement ce qui est fourni par l'instantané. Les packages installés à partir de chaque instantané sont enregistrés dans des bases de données distinctes, qui n'interfèrent pas les unes avec les autres..cabal
project.yaml
Nous pourrions dire que l' approche de la pile échange une certaine flexibilité de configuration pour la simplicité lorsqu'il s'agit de spécifier une configuration de construction. En particulier, si vous savez que votre projet utilise, par exemple, l'instantané LTS 15.3, vous pouvez accéder à sa page Stackage et connaître, d'un coup d'œil, les versions de toute pile de dépendances qui pourraient être extraites de Stackage. Cela dit, les deux outils offrent des fonctionnalités qui vont au-delà des flux de travail de base afin que, dans l'ensemble, chacun puisse faire tout ce que l'autre fait (bien que peut-être d'une manière moins pratique). Par exemple, il existe des moyens de figer les versions exactes d'une bonne configuration de construction connue et de résoudre les dépendances avec un ancien état de Hackage avec cabal-install, et il est possible d' exiger des dépendances non-Stackage ou de remplacer les versions de package d'instantanés lors de l'utilisation de stack .
Enfin, une autre différence entre cabal-install et stack qui est suffisamment importante pour être mentionnée dans cet aperçu est que la stack vise à fournir un environnement de construction complet, avec des fonctionnalités telles que la gestion automatique de l'installation GHC et l' intégration Docker . En revanche, cabal-install est censé être orthogonal à d'autres parties de l'écosystème, et ne tente donc pas de fournir ce type de fonctionnalité (en particulier, les versions de GHC doivent être installées et gérées séparément, que ce soit via la distribution Linux packages, Haskell Platform Core sous Windows ou l’outil ghcup ).
cabal-install
et utilise le stackage autant que possible - il pourrait y avoir une certaine rétro-intégration dans cabal-install à un moment donné et je pense la communauté ne sait pas si c'est une bonne chose ou pas, car cela pourrait diviser la communauté)