Je pense que personne ne voulait faire référence aux dépendances directes, mais bien aux dépendances vers des paquets Haskell (directes ou indirectes, sans compter les paquets standard qui viennent avec GHC), qui sont au moins au nombre de cent.
Mais c'est plus une observation qu'une critique en ce qui me concerne, au sens, si un jour Haskell devient très populaire et tous les OS disposent de suffisamment de main d'œuvre pour assurer un support de base fiable de tous ces paquets, ça deviendra raisonnable pour plus de monde, comme pour d'autres logiciels connus en C/C++/Python/... tout sauf minimalistes et avec beaucoup de dépendances. En attendant, il faut juste être conscient que dépendre de pandoc est un choix personnel, dans le sens où ça ne me surprendrait pas que sur un OS ou distrib donnée, des difficultés empêchent occasionnellement d'utiliser le logiciel pendant plusieurs semaines/mois/années — si j'ai fui pandoc il y a déjà quelques années, c'était en partie parce que je me suis justement retrouvé à ne pas réussir à le compiler sous OpenBSD à un moment donné et que je n'ai pas suffisamment l'âme d'un packageur pour y passer des heures et des heures.
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.
En effet, ce n'est pas étonnant, il s'agit plutôt d'un choix, typique pour des logiciels dans des langages comme Haskell/Python/Perl/Javascript : priorité à intégrer un maximum de fonctionnalités en réutilisant ce qui est fait ailleurs (même de tous petits paquets), même si ça explose le nombre de dépendances. Ça a du bon comme du mauvais.
[^] # Re: Pandoc
Posté par anaseto . En réponse à la dépêche Trois outils pour développeur : MailHog, Tokei et Pandoc. Évalué à 4.
Je pense que personne ne voulait faire référence aux dépendances directes, mais bien aux dépendances vers des paquets Haskell (directes ou indirectes, sans compter les paquets standard qui viennent avec GHC), qui sont au moins au nombre de cent.
Mais c'est plus une observation qu'une critique en ce qui me concerne, au sens, si un jour Haskell devient très populaire et tous les OS disposent de suffisamment de main d'œuvre pour assurer un support de base fiable de tous ces paquets, ça deviendra raisonnable pour plus de monde, comme pour d'autres logiciels connus en C/C++/Python/... tout sauf minimalistes et avec beaucoup de dépendances. En attendant, il faut juste être conscient que dépendre de pandoc est un choix personnel, dans le sens où ça ne me surprendrait pas que sur un OS ou distrib donnée, des difficultés empêchent occasionnellement d'utiliser le logiciel pendant plusieurs semaines/mois/années — si j'ai fui pandoc il y a déjà quelques années, c'était en partie parce que je me suis justement retrouvé à ne pas réussir à le compiler sous OpenBSD à un moment donné et que je n'ai pas suffisamment l'âme d'un packageur pour y passer des heures et des heures.
En effet, ce n'est pas étonnant, il s'agit plutôt d'un choix, typique pour des logiciels dans des langages comme Haskell/Python/Perl/Javascript : priorité à intégrer un maximum de fonctionnalités en réutilisant ce qui est fait ailleurs (même de tous petits paquets), même si ça explose le nombre de dépendances. Ça a du bon comme du mauvais.