Un résumé de mes frustrations sur Github récemment :
— Je suis à la lettre les commandes d’un README. J’obtiens erreur sur erreur. Je soumets un rapport de bogue.
— On me répond qu’il ne fallait pas utiliser la branche maître, mais une autre branche. Bon. Toujours erreur sur erreur.
— On m’informe qu’il ne faut pas suivre les commandes du README. On me donne d’autres commandes.
— Erreur sur erreur. Il fallait installer des logiciels supplémentaires.
— J’attends la réponse du développeur.

La personne est très gentille : elle réponds à mes rapports de bogue avec des suggestions. Mais bon, ça n’inspire pas vraiment confiance… Et ça doit faire fuir beaucoup, beaucoup de monde de faire cela. Je me trouve déjà pas mal motivé de continuer malgré les erreurs.

Enfin : le projet est relié à Travis CI. Ça fait six mois que les développeurs envoient des modifications régulières et que Travis rejette toutes les modifications… ce qu’ignorent les développeurs. À quoi ça sert une intégration continue, déjà ? 🤔​

Follow

En passant, pour tous les gens qui galèrent à fournir un README correct pour et à le mettre à jour, voici deux conseils simples :
— Utilisez esy. Franchement. Ce n’est pas très compliqué à mettre en place et ça donne beaucoup plus de garanties sur les applications installées sur le système. En pratique, il faut ajouter un fichier json qui ressemble à ça : github.com/esy/esy/blob/master Ça contient le nom du programme, ses dépendances, et comment le compiler, en gros.
— Mettez en place une intégration continue (il faut ajouter un fichier qui ressemble à ça github.com/esy/esy/blob/master qui ne fait qu’installer npm, esy, et appeler ce dernier pour compiler et tester votre projet). Si l’intégration continue est rejetée, c’est qu’il y a une erreur grave dans votre code : vous ne pouvez pas partir du principe que ça va marcher chez l’utilisateur si ça ne fonctionne même pas dans un environnement contrôlé.

Si vous pouvez documenter (mais comment vous ne pourriez pas le faire ?), faites le. Mais utilisez , sérieux.

@MartinShadok donc maintenant faut un fichier opam, un fichier ezy, c'est quoi le prochain ? 🙂

@oranadoz Alors esy est basé sur opam ☺ Donc ça ne réinvente pas la roue non plus. En particulier, on n’a pas besoin de faire un fichier opam si on fait un fichier esy ☺ La grosse différence, c’est que l’on liste explicitement toutes les dépendances, et esy donne un environnement qui ressemble à docker : on n’a plus accès à notre propre environnement. Autrement dit, si ça compile sous esy, ça va compiler ailleurs. Opam ne donne pas cette garantie, ce qui est source de quantité de problème (je n’ai jamais réussi à compiler un projet opam du premier coup, c’est dire…).

@MartinShadok Je regarde.... Déjà je vois que c'est inspiré de npm, je me retiens de faire CTRL-W...
Ah, ensuite je vois que ça s'installe avec npm. Bon ben là c'est CTRL-W direct.

/me regarde l'horizon en me demandant ce qui pousse les développeurs à empiler les bouses au détriment de l'espace disque, du temps de calcul et de la bande passante... 🤔

@oranadoz C’est basé sur npm, oui. Ça ne veut pas dire que ça installe du JavaScript à tout va : même si npm est largement utilisé pour installer du JavaScript… c’est avant tout et surtout un programme pour installer des fichiers avec des dépendances. L’idée d’esy consiste juste à télécharger des fichiers OCaml avec. Quel est le problème, du coup ?

@oranadoz L’argument de l’espace disque est très bancale : esy tente de partager le plus possible entre les différentes dépôts. La partie JavaScript est très clairement négligeable devant le OCaml téléchargé.

L’argument du temps de calcul est lui aussi très bancal : la gestion des dépendances est complètement négligeable devant la compilation du OCaml.

La bande passant, c’est juste de la mauvaise fois, là : que ça soit via esy ou opam, ce sont les mêmes fichiers qui sont téléchargés.

C’est parce que c’est compatible avec Windows que ça gène, en fait ? 🙃​

@MartinShadok Alors tout d'abord je signale que, d'expérience, tout ce qui s'appelle easy-machin, ezy-bidule, izy-truc, ... fonctionne en général en normalisant fortement ce qu'il est possible de faire, l'utilisateur étant invité à ne plus se poser de questions. En conséquence, quand ça ne marche pas, on n'a peu de prises; et quand on veut sortir du cadre prévu, c'est la galère. Au fur et à mesure qu'il faut intégrer les cas non gérés, l'outil se complexifie pour coller davantage à la réalité.

@MartinShadok Là de ce que je comprends, il y a une incitation forte à avoir un container par projet qu'on développe. Je ne connais pas le niveau de partage, mais j'imagine que ça a tendance à faire grossir la place prise par l'environnement, environnement qu'il faut créer (donc calculs).
L'argument de la bande passante peut te sembler de mauvaise foi, mais comme je ne connais pas la finesse du partage effectif, je peux imaginer qu'il y a retéléchargement de tout pour un nouveau container[...]

@MartinShadok [...] et sinon il y a des archives qui trainent et qui prennent de la place. J'ai peut-être tort, mais existe-t-il des études précises d'utilisation de l'espace disque et des téléchargements dans des cas usuels ?

@MartinShadok Il va sans dire que la compatibilité avec Windows n'est pas un argument qui plaide en sa faveur 🙂

@oranadoz Effectivement, esy a le même problème qu'opam : si on change la version du compilateur parce que le logiciel évolue, on reste avec la version précédente installée. On peut la supprimer, bien sûr, mais c'est rarement fait en pratique. Je ne connais aucune étude sur les comportements des utilisateurs là dessus.

Maintenant, ces problèmes sont aussi rencontrés par opam : ils ne sont donc pas des arguments valides pour rester sur ce dernier…

Je veux bien croire qu'esy n'est pas génial, mais il va me falloir des vrais arguments. Juste dire « ça utilise du JavaScript de manière négligeable lors de la gestion de certaines dépendances », ce n'est clairement pas un argument.

@MartinShadok C'est plutôt la multiplication des conteneurs qui m'ennuient (mais je n'ai pas testé) et le fait que ça rajoute encore un truc sur la pile, non pas à la place d'opam, mais en +, puisque tu me dis que ça l'utilise.

@oranadoz Ça l'utilise sous le capot, oui. Mais ni le développeur ni l'utilisateur n'a à s'en soucier. Donc bon, ça n'allourdi pas grand chose.

@MartinShadok Sauf quand il s'agit de trouver où ça foire, en général le nombre de couches et le manque de contrôle sur chacune est une source de problème, d'où ma réticence, en plus de mes doutes.

@oranadoz De ce que je sais, ça fonctionne comme Nix : chaque version de bibliothèque n'est téléchargé et compilée qu'une seule fois sur tout le système. Je ne vois pas comment om peut faire mieux…
Après, si on utilise Nix sur un projet, esy sur un autre, et opam sur un troisième, oui, il y a duplication. Mais ce n'est pas la faute de l'un ou de l'autre.

@MartinShadok Mais puisque, d'après ce que j'ai compris, pour chaque petit projet tu refais un conteneur correspondant aux dépendances, il suffit que les dépendances varient un peu pour que tu recompiles tout, alors qu'un conteneur existant suffisait peut-être, comme un switch d'opam fonctionne pour plusieurs projets. Je veux dire que souvent les dépendances indiquées sont plus fortes que nécessaires, d'où cette conséquence.

@oranadoz C'est vrai. Mais du coup on n'a pas exactement les mêmes versions des outils côté développeur et côté utilisateur pour opam… et dans mon expérience, c'est souvent source de problème.

D'ailleurs, la première chose que l'on fait lorsqu'on rapporte un bug pour un projet opam, c'est de lister les versions d'un peu tout : comme opam ne donne que peu de garanties sur celles qui seront installées, on a vite fait de rencontrer une situation non prévue 😕

@MartinShadok Aec opam, tu peux toujours (demander de) forcer l'installation d'une version précise, non ?

@oranadoz Oui, mais très rare sont ceux qui ouvrent une machine virtuelle vide dans un environnement qui redirigent les connexions aux serveurs d'opam vers une version précédente ou suivante pour vérifier qu'ils ont bien indiqué les bonnes versions de tous les paquets *et leurs dépendances*. La tâche est d'ailleurs tellement monumentale que sans un gestionnaire comme esy ou Nix, tu es assuré d'oublier des choses.

@oranadoz Ça c'est tout à fait vrai. Mais ça n'a rien à voir avec les trois autres arguments.
Cependant, c'est assez rare que l'on ne colle pas au cadre prévu en OCaml (en Coq, je ne dis pas 😅).

@MartinShadok Ca n'a rien à voir mais c'est pour expliquer mon ultra-réticence a priori 🙂

Il y a une ambiguïté dans ta seconde phrase: qui est "on", et est-ce "au cadre (prévu en OCaml)" ou "(au cadre prévu)" (par quoi) "en OCaml" ?

@oranadoz Ah mais je comprends ta réticence ! Mais critiquer un projet libre sans argument, c'est de mauvais goût. (Mais si esy te fais des boutons, utilise Nix, hein, c'est très bien aussi 😊)

Je voulais dire « le cadre prévu par esy » ☺️ Par « on » je parle des projets OCaml dont j'ai lu le code source jusque là : les miens, mais aussi ceux que j'ai essayé d'installer.

@MartinShadok J'émets des doutes sur les conséquence en terme de place et de calcul, qui d'ailleurs ne sont pas levés 🙂

@MartinShadok Si les projets OCaml rentrent bien dans ce cadre, c'est peut-être parce qu'il y a déjà eu une grosse normalisation avant, notamment depuis opam. Heureusement, on reste encore libre pour l'outil de build...

@oranadoz À noter que l’on peut aussi compiler esy depuis ses sources : il n’est pas nécessaire d’installer npm pour installer esy. Et npm n’est pas une dépendance d’esy : on peut utiliser esy sans npm (le binaire, j’entends).

Côté connexions, esy va communiquer avec les serveurs npm lorsqu’on lui demande d’installer une dépendance depuis npm, et c’est tout. Si on lui demande d’installer une dépendance depuis opam, esy va faire les mêmes requêtes qu’opam (donc vers github.com, puis probablement—ça dépend du paquet—vers github.com, ocamlpro.com erratique.ch, ou janestreet.com). Autrement dit… esy va faire les mêmes connexions que les autres gestionnaires de paquets OCaml.

@MartinShadok Bizarre tes soucis avec opam. J'ai souvent pu installer des bibliothèques avec et j'ai toujours du mal à voir l'intérêt d'esy, du coup. Par contre, opam ne résoud pas plusieurs problèmes:
1. La vitesse folle de sortie de nouvelles versions d'ocaml et autres bibliothèques, avec casse de codes existants
2. Le fait que des gougnafiers modifient les contraintes de paquets dont ils ne sont pas mainteneurs dans le dépôt opam et qui empêchent des installations possibles.

@oranadoz Il y a deux problèmes principaux avec opam.

Le premier, c'est qu'il est global au système. Donc à chaque fois que je change de dossier, je dois faire un “opam switch”. C'est très très relou quand on bosse sur plusieurs projets en même temps.

Le second, c'est que globalement, opam est souple. Sous esy, si tu n'as pas indiqué une dépendance, tu ne peux pas l'utiliser même si tu l'as installé à la main sur le système. Conséquence : les développeurs qui utilisent opam oublient systématiquement des dépendances. Esy garanti que les dépendances disponibles sont les mêmes côté développeurs et côté utilisateur. Ça permet d'être certain que n'importe qui peut utiliser ton logiciel, et ça, c'est le minimum.

@MartinShadok Avec souvent pour conséquence des dépendances trop strictes. Mais est-ce grave que le développeur ait oublié une dépendance ? Il suffit de lui dire, ou mieux, il suffit de le dire au mainteneur du paquet, sans faire ch... le développeur s'il est différent du mainteneur.

@oranadoz Je suis dans un contexte de recherche dans mon usage le plus fréquent. Dans ce contexte, il n'y a pas de mainteneur, et le développeur est souvent un thésard qui a passé sa thèse entre-temps et bosse maintenant sur autre chose. Donc oui, ça fait vraiment chier lorsqu'on doit rapporter un bug à la con parce que personne n'a eu l'idée de noter les versions des bibliothèques.

@MartinShadok Dans un contexte de reproductibilité (et de précarité) en effet ça peut être bien qu'un truc vérifie que toutes les dépendances sont bien listées. Et c'est exactement ce genre de besoin de reproductibilité qui va faire lister des dépendances très précises (numéro de version au lieu de version <= X et > Y) et entraîner la création d'une multitude d'environnements.

@oranadoz Je n'ai jamais vu aucun chercheur faire ça. C'est juste trop de travail sans utiliser un logiciel comme esy ou Nix.

@MartinShadok Ce que je veux dire, ce n'est pas que le chercheur va tout tester, c'est que si on parle reproductibilité, alors il faut les versions exactes des bibliothèques utilisées. Donc si je veux utiliser X alors ça me fait un environnement avec une combinaison donnée, et pour utiliser Y, j'ai un autre environnement avec une autre combinaison, etc., donc peu de partage.

@oranadoz Je suis d'accord jà dessus. Mais pour le coup ce n'est pas vraiment de la faute de qui que ce soit 😕

@MartinShadok Donc il faudrait pouvoir avoir (au moins) deux confs: une, précise, pour la reproductibilité, l'autre pour l'utilisation «classique» où on ne veut pas être aussi précis.

@oranadoz Je ne suis pas d'accord : tout programme peut finir dans les dépendances de quelqu'un d'autre. La dernière chose que tu veux, c'est qu'opam plante quand tu compiles tes dépendances : toute dépendance doit pour moi être en mode reproductible. Au final, tu ne vas de toutes façons pas partager beaucoup de choses. 😕

@MartinShadok Ce que je veux dire, c'est que si tu veux marquer une version comme permettant de reproduire une expérience, mieux vaut indiquer précisément toutes les dépendances (n° version == X.Y.Z), pour le cas (connu ou pas) où une dépendant change de comportement et le résultat de ton expérience. Mais tu peux aussi vouloir que ton code soit embarqué dans un autre sans cette précision, charge à l'embarquant de faire gaffe sur ce changement de comportent pas forcément non désiré.

@MartinShadok Pour moi la reproductibilité, c'est pas juste pouvoir compiler, donc la question de savoir si opam plante pendant l'install des dépendances n'a rien à voir.

@oranadoz Ce n’est pas juste ça, mais c’est en partie ça : ça a carrément à voir.

@MartinShadok (Oups, je revenais du site d'esy donc je suis resté sur l'anglais sans réfléchir ^^)

@otini Pas de problème 😊​

Par contre, je ne suis pas certain d’avoir compris la question. Tu as un exemple concret ?

Puisqu’esy est basé à la fois sur npm et sur opam, j’ai envie de dire que les dépendances supportées sont nombreuses. Dans la pratique, je n’ai jamais eu besoin d’inclure des choses trop compliquées, donc je ne peux pas dire grand chose ☺

@MartinShadok Pardon, ma question n'était pas claire. Je me demandais s'il faut compiler toutes les dépendances qui sont des paquets opam, ou bien s'il y a une possibilité d'installer directement des binaires.

@otini Ah oui, je comprends. Je ne sais pas faire (j’utilise les paquets opam, donc ça recompile tout…). Je pense cependant que (au moins théoriquement) c’est possible : npm permet d’importer des choses sans les recompiler. Le hic, c’est que je ne sais pas qu’il existe des dépôts compatibles avec esy qui contiennent les binaires précompilés 😕

@MartinShadok Ou juste nix, comme ça même pas besoin d'installer npm...

@MartinShadok @samae

Pour une fois que ce n'est pas moi qui parle de Nix en solution :)

Sign in to participate in the conversation
Aleph

Generalistic Mastodon instance for open-minded people. Instance Mastodon généraliste pour personnes ouvertes d'esprit.