Sommaire
Ça fait quelque temps que j'avais envie de partager mes réflexions sur le packaging et mon expérience concrète avec LuaUnit.
En tant qu'auteur de logiciel, j'aime quand mon logiciel est utilisé. Plus il a d'utilisateurs, plus je suis content et fier: je contribue de façon utile au grand monde du logiciel libre.
Pour avoir plein d'utilisateurs, il a plusieurs étapes:
- écrire un logiciel qui rend un service utile
- les gens qui ont besoin du service en question trouvent le logiciel
- ils installent le logiciel
- ils s'extasient devant la qualité du logiciel, la beauté du code source et décident immédiatement de léguer toute leur fortune à l'auteur du logiciel.
Sachant que l'être humain est globalement plutôt flemmard, il va renoncer à installer un logiciel si il rencontre le moindre micro-obstacle aux étapes 2 et 3. Par exemple, moi, je vais facilement renoncer si le logiciel s'avère trop fastidieux à installer.
Ma première découverte du packaging
Lorsque je faisais mes études, le langage en vogue s'appelait: Perl. Il avait un truc très fort - Perl - c'était le CPAN: une archive de plein de programmes Perl, facile à découvrir et à installer. A l'époque, c'était très innovant. Un ami m'avait montré comment trouver et installer en une minute un programme pour un besoin spécifique, ça m'avait bluffé! Le CPAN a très fortement contribué à la popularité de Perl. En dehors du monde du Perl, la meilleure source pour trouver un logiciel était alors freshmeat.net mais c'était beaucoup plus aléatoire en terme de résultat.
Par la suite, les autres langages de programmation ont bien saisi l'importance du packaging et repris la même idée. Rendre facile la découverte et l'installation de bibliothèques ou programmes autonomes via une archive centrale: Python avec PyPi, node.js avec NPM, Rust avec Cargo, Ruby avec les Gems, etc etc.
LuaUnit et le packaging
Maintenant, parlons de LuaUnit, mon bébé logiciel libre. Dans un épisode précédent, je vous racontai comment un fork avait heurté mon ego et comment GitHub avait ressuscité mon projet moribond
Une des choses qu'avait fait l'auteur du fork de mon LuaUnit, c'est d'en faire le packaging. Dans le monde Lua, ça s'appelle un Rock et c'est centralisé sur LuaRocks .
Bien que je sois intimement convaincu de l’intérêt du packaging (comme je l'ai décrit plus haut), j'hésitais à franchir le pas. LuaUnit était déjà très facile à installer, il suffit de copier le fichier luaunit.lua dans votre projet et c'est parti. Est-ce que j'avais vraiment besoin de me pencher sur le packaging ? OK, son paquet avait tout de même 30 000 téléchargements … Je pense que j'étais freiné par le fait d'avoir une confrontation directe entre son LuaUnit et le mien. Chacun dans son coin, c'est plus simple et plus confortable.
J'ai décidé de prendre mon temps avant de me lancer dans une confrontation. J'ai d'abord sorti deux versions sur GitHub (la 3.0 et la 3.1), avec des avancées majeures par rapport à l'existant: une documentation très détaillée, de l'intégration pour Jenkins, de grosses améliorations sur l'affichage des tables et notamment des tables récursives, et plein de test internes. Le tout validé en intégration continue sur Travis CI et AppVeyor. Après deux années de travail, pour la 3.2, c'était décidé: il y aurait un rock pour mon LuaUnit. les avancées était suffisamment significatives pour que les utilisateurs choisissent de mettre à jour sans hésiter vers ma version.
J'ai donc préparé un Rock pour LuaRocks. La documentation était relativement claire, je n'ai pas eu de difficulté. Je l'ai téléversé dans mon espace de nom sur LuaRocks: c'est comme sur GitHub, un package est associé à un espace de nom de sorte que personne ne se marche sur les pieds. Il me restait un petit problème à résoudre: la version LuaUnit de rjpcomput0ing était référencée dans le manifest core de LuaRocks. Cela signifiait que cette version était celle installée par défaut si on tapait: luarocks install luaunit
Alors que pour installer la mienne, il fallait faire: luarocks install bluebird75/luaunit
L'autre souci, c'est que les utilisateurs ne pouvaient pas faire une mise à jour transparente de son LuaUnit vers le mien. Il fallait forcer une mise à jour vers mon espace de nom luarocks install bluebird75/luaunit.
J'ai contacté le mainteneur du manifest core pour lui expliquer la situation. Il a contacté l'auteur de mon fork pour voir ce qu'il en était et ce dernier a gentiment accepté de laisser mon package prendre la place du sien. Sa version n'avait pas bougé depuis deux ans donc la demande était raisonnable. Je lui suis très reconnaissant d'avoir accepté. Afin que la mise à jour soit transparente, j'ai uploadétéléversé son paquet sur mon espace de nom et mon LuaUnit est entré dans le manifest core.
Ce qui est sympa avec LuaRocks, c'est qu'il y a un compteur de téléchargement. Je suis allé voir au bout de quelques jours ce que cela donnait. Et là, je suis tombé sur le c** ! Je m'attendais à voir au mieux 2 ou 3 téléchargements par jour. Après tout, Lua est un langage relativement confidentiel, et il y a déjà plusieurs projets de tests unitaires. Combien y a-t-il de personnes sur terre qui se disent tiens, je commence un projet en Lua, voyons ce qu'il y a comme lib de test unitaires ? ou tiens, si je mettais à jour ma lib de test unitaires sur mon projet Lua ? La réponse est: beaucoup !
LuaUnit était téléchargé au rythme de 250 téléchargements par jour. En deux mois, j'ai dépassé les 10 000 téléchargements! A l'heure où je vous parle, LuaUnit a été téléchargé en cumulé plus de 300 000 fois !!! Je n'en reviens toujours pas. J'ai essayé de voir s'il n'était pas téléchargé automatiquement par autre chose que LuaRocks mais rien n'indique que cela soit le cas.
Fasciné par ce nombre de téléchargements en croissance, j'ai fait un petit script qui me récupère ce statut tous les jours. Je voulais archiver ce truc incroyable et voir si ça se maintenait dans le temps.
Voici ce que ça donne dans un graphe:
On voit bien mes 250 téléchargements par jour du début. Puis un plateau entre 500 et 700 de novembre 2016 à août 2017. Je n'ai aucune explication pour ce plateau, peut-être un artifice de LuaRocks ? En tout cas, LuaUnit se télécharge intensément, même aujourd'hui (un peu moins de 100 fois par jour) ! Même si les métriques de LuaRocks sont faussées, j'ai constaté la popularité certaine de mon bébé. Par exemple, j'ai pas loin d'une nouvelle étoile sur GitHub par semaine, signe que des utilisateurs le trouvent et l'utilisent.
Mon script collecte deux ou trois autres métriques, dont je vous reparlerai à l'occasion.
Conclusion
En tout cas, si vous avez un doute sur l'intérêt du packaging, n'en ayez plus. Ca fait une pu**** de différence en terme de popularité.
Je remercie encore chaleureusement mon forkeur, grâce à qui j'ai pu créer un logiciel téléchargé plus de 300 000 fois :-)
# Attention au stats
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Luanit est un framework de tests unitaires. Dans un projet, il est donc susceptible d'être lancé à chaque push sur le dépôt du projet, si il y a de l'intégration continue.
Normalement, dans un système d'intégration continue bien fait et bien configuré, les dépendances externes ne sont installés au moment du lancement des tests que quand leur version change ou qu'elles sont nouvelles. Dans gitlab-ci, il est ainsi possible de mettre par exemple un répertoire de dépendances comme node_modules (paquets npm), dans un cache. À chaque lancement de l'intégration continue, gitlab-ci, créé les répertoires de dépendances à partir de son cache. Cela évite au packageur (ici npm), de re-télécharger tous les paquets.
Mais ça c'est quand c'est bien fait.
Il y a des projets où c'est mal foutu : utilisation d'un outil d'intégration continue pas cool, ou mal configuré.
Du coup, à chaque push sur le dépôt d'un de ces projets, téléchargement systématique des dépendances. Sur un projet bien actif, cela peut en provoquer des dizaines par jour. (Pour SlimerJS, j'avais eu des soucis d'un serveur de je ne sais où qui téléchargeait toutes les 2-3 minutes le paquet : il me bouffait toute la bande passante de mon serveur d’hébergement !)
Du coup, les statistiques ne veulent pas dire grand chose. Cela ne correspond pas au nombre d'utilisateurs, donc à la popularité de l'outil.
Disons que c'est une popularité artificielle, qui peut avoir tout de même un bénéfice : avec des stats gonflées ainsi artificiellement, cela propulse le paquet dans les hauteurs des classements des "projets les plus utilisés", donc ça incite plus facilement à ceux qui doivent choisir, d'utiliser le projet en question. Ce qui fait encore plus gonfler les stats etc..
[^] # Re: Attention au stats
Posté par barmic 🦦 . Évalué à 2.
C'est le cas de toutes dépendances en fait. En principe ça ne biaise pas les comparaisons. À moins que luaunit soit particulièrement utilisé par ceux qui configurent mal leur CI.
Et il reste l'étoile sur github qui n'est probablement pas ajoutée automatiquement ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Attention au stats
Posté par Philippe F (site web personnel) . Évalué à 6.
J'ai quand même un élément de comparaison: le LuaUnit de mon forkeur était moins populaire. En 2 ans, il avait fait un peu moins de 30 000 hits sur luarocks. J'ai fait ça en 4 mois à peu près. Donc mon LuaUnit est devenu plus populaire.
J'avais pas pensé à l'utilisation en CI. Comme j'ai rajouté une sortie au format TAP et une sorite au format Junit XML (Jenkins/Hudson en gros), il est possible que des développeurs se soient rués là dessus pour le mettre en CI. Donc, soit ils sont très nombreux à avoir fait ça, soit il s'agit de projets hyper dynamiques … soit les deux.
Je ferai un autre article sur la popularité de LuaUnit d'après d'autres stats. En tout cas, ça fait du bien au moral !
[^] # Re: Attention au stats
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
L'augmentation des stats reste bon signe, c'est certain. Good job!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.