Dans les points qui me chagrinent un peu dans ce logiciel, c'est [...] surtout le nombre de dépendances (exagéré même selon les standards Haskell, autour de 100 !) [...]
moins d'une soixantaine si on veut le binaire pandoc
une dizaine de plus si on ajoute le binaire trypandoc
Néanmoins, l'histoire est tout autre si l'on ajoute les dépendances transitives ; mais dans ce cas, on arrivera à bout du compte à reprocher à Pandoc de dépendre de la glibc et équivalents :)
Au-delà de cette banale comptabilité, la vraie question consiste dans le pourquoi de toutes ces dépendances et la réponse est donnée dans l'aide du logiciel : "Pandoc includes a Haskell library and a standalone command-line program. The library includes separate modules for each input and output format, so adding a new input or output format just requires adding a new module." que je traduis de la sorte :
« Le projet Pandoc englobe une bibliothèque et un binaire à lancer sur la ligne de commandes. La bibliothèque se sert d'un module dédié afin de traiter chaque format d'entrée (respectivement de sortie) [...] »
Généralement, les modules Haskell suffisamment distincts les uns des autres se retrouvent dans des paquets différents. Vu la quantité de formats que supporte Pandoc et sans parler des extensions (à la fois celles mentionnées dans la dépêche et celles-ci), il n'est pas étonnant d'avoir des dizaines de paquets comme dépendances.
Cela dit, étant donné à qui je répond, je n'ai pas de doute que ma logorrhée supra est superflue, la personne en question étant sans doute déjà au courant de tout ça. Peut-être que la partie citée au début de ce commentaire était sarcastique. Plus important, en 2018, on ne devrait plus utiliser cabal install pandoc pour compiler Pandoc comme dans le courriel de Matthias Kilian ; il est temps de rafraichir les workflows et de passer à cabal new-build pandoc et consorts.
[^] # Re: Pandoc
Posté par gipoisson . En réponse à la dépêche Trois outils pour développeur : MailHog, Tokei et Pandoc. Évalué à 7.
Factuellement, les courriels de Matthias Kilian et d'Ingo Schwarze ne sont pas corrects quant au nombre de dépendances directes de Pandoc car celui-ci n'atteint pas la centaine :
Néanmoins, l'histoire est tout autre si l'on ajoute les dépendances transitives ; mais dans ce cas, on arrivera à bout du compte à reprocher à Pandoc de dépendre de la glibc et équivalents :)
Au-delà de cette banale comptabilité, la vraie question consiste dans le pourquoi de toutes ces dépendances et la réponse est donnée dans l'aide du logiciel : "Pandoc includes a Haskell library and a standalone command-line program. The library includes separate modules for each input and output format, so adding a new input or output format just requires adding a new module." que je traduis de la sorte :
« Le projet Pandoc englobe une bibliothèque et un binaire à lancer sur la ligne de commandes. La bibliothèque se sert d'un module dédié afin de traiter chaque format d'entrée (respectivement de sortie) [...] »
Généralement, les modules Haskell suffisamment distincts les uns des autres se retrouvent dans des paquets différents. Vu la quantité de formats que supporte Pandoc et sans parler des extensions (à la fois celles mentionnées dans la dépêche et celles-ci), il n'est pas étonnant d'avoir des dizaines de paquets comme dépendances.
Cela dit, étant donné à qui je répond, je n'ai pas de doute que ma logorrhée supra est superflue, la personne en question étant sans doute déjà au courant de tout ça. Peut-être que la partie citée au début de ce commentaire était sarcastique. Plus important, en 2018, on ne devrait plus utiliser
cabal install pandocpour compiler Pandoc comme dans le courriel de Matthias Kilian ; il est temps de rafraichir les workflows et de passer àcabal new-build pandocet consorts.