Re: Superbe article, bravo

Merci pour ce retour.

Concernant le packaging, c'est vrai que c'est un peu le foin. Un package Haskell est assez bien décrit avec un fichier .cabal. stack, nix, bazel savent charger les fichiers .cabal. Hackage travaille avec les fichiers .cabal. Bref, la norme si tu veux redistribuer c'est .cabal et cela marche pas trop mal.

Si tu ne veux pas redistribuer, tu peux construire ton projet avec du hpack (+nix ou stack), du bazel pure, du nix pure, libre à toi en fonction de la complexité de ton projet. Sur les gros projets sur lesquels je travaille, 450 packages Haskell pour plus de 1000 modules, la solution à base de .cabal ne scale pas et nous utilisons bazel, mais on pourrait utiliser des .cabal, c'est juste beaucoup trop verbeux pour nos besoins. hpack pourrait être une solution aussi. Mais bien souvent, un package se résume à:

haskell_library(
 name = "mypackage",
 srcs = glob(["**/*.hs"]),
 deps = ["@hackage//:base", ...]
)

Nix apporte une chose qu'aucun des autres système n'apporte, c'est le coté parfaitement reproductible. Mais je ne connais pas de langage qui ai un système de package qui apporte aussi cette garantie, donc en fait je me sert de Nix avec tout langages, pas juste Haskell.

cabal et stack (les outils) souffrent de ne pas être reproductible parfaitement, mais si ce n'est pas une garantie que tu recherches, les deux font le travail aussi bien que n'importe quel autre outil pour d'autres langages. stack vient avec les snapshot de stackage qui apportent un coté pratique pour avoir un peu plus de reproductibilité.