hg , git , mon cul, oui !

La semaine dernière, j’ai voulu expérimenter une idée que j’ai depuis un moment : exporter les logs de SVN dans un fichier lisible par Gephi sous forme d’un graphe dynamique, c’est-à-dire un graphe dont les noeuds, et les arcs, changent au cours du temps.Cette idée n’est évidement pas nouvelle, pusique c’est la racine du script Gource. Ce que je voulais (présomptupeusement peut-être) amener, c’est la possibilité de ne pas simplement consulter l’évolution de ce graphe, mais aussi interragir avec lui pour, par exemple, isoler des clusters, c’est-à-dire des groupes de fichiers modifiés en même temps, et donc ayant de fortes chances d’être corrélées. Tous les javaistes me répondront que c’est facile de trouver des classes conceptuellement proches, grâce à des outils d’analyse de code comme JDepend.Oui, mais là, en l’occurence, ça n’est pas du Java. Ni du Ruby/Groovy/Python/… Ni aucun langage publiquement connu, en fait. Donc, il est « théoriquement » impossible, sans outil d’analyse de ce type, de connaître les liens entre fichiers.
Mon hypothèse était donc d’imaginer que, si deux fichiers sont commités simultanément, alors ils ont un lien. Et Gephi, grâce à ses outils de layout de graphe (je vous aurais bien mis un lien vers une liste des layouts disponibles, mais je n’en ai pas trouvé) peut me permettre de voir ces liens.
Il me restait donc à retrousser mes manches pour récupérer la liste des commits SVN avec les fichiers associés, pour les injecter dans Gephi. Pour ça, j’avais évidement besoin de deux composants :
  1. Un outil de lecture des commits SVN (coup de bol, ça existe, c’est utilisé dans Eclipse, et le plus facile à intégrer dans du code s’appelle SVNKit)
  2. Un outil d’écriture des fichiers GEXF (les fichiers contenant les graphes de Gephi) en Java). Et là, ça se corse.
Et on arrive au point qui donne son titre à ce mail.
Dans mes flux (ou dans Twitter, je ne sais plus), j’avais vu qu’un type lisait le contenu d’une base Oracle pour le mettre dans Gephi avec … du Groovy ! Pas con, hein, parce que Groovy est parfaitement et totallement adapté à ce genre de tâches.
N’écoutant que mon courage, j’ai donc regardé comment il faisait. Simple, avec une librairie, gexf4j, qui permet précisément de mapper un fichier GEXF vers des classes Java dédiées (et donc, potentiellement, bien fichues). Issu du monde le plus Java, je me suis logiquement dit que cette librairie, compilée avec Maven et Open-source, devait être disponible sur un quelconque repository. Las, mvnbrowser et jarvana m’ont tous deux donné la même réponse : nada. Du coup, je me suis dit « pas de problème, je télécharge le jar, je l’installe dans mon repository local, et un coup de @grab suffira ! Seulement si vous regardez bien le site de cette bibliothèque (qui en fait, doit déja être implémentée, sous une forme ou une autre, dans Gephi, qui est complètement codé en Java/Swing), vous pourrez lire cette phrase :

Only sources in GZIP are available for unstable versions.

Je vous demande pardon ? 
Donc il n’y a pas de version stable, et je ne peux télécharger que le source de la version instable ? euh … c’est pas un peu cavalier ça ?
Les choses empirent : en cliquant sur le lien, vous verrez qu’il vous envoie sur GitHub. Donc en fait, il n’y a pas de zip des sources. Il faut en fait cloner le dépôt en l’état (bugs included), et compiler chez soi.
Passé le premier moment d’incompréhension, je me suis dit « bon, ok, c’est un petit jeune plein de fougue qui veut pas s’emmerder avec du packaging consomateur de temps. Pourquoi pas ». Je me suis alors fait la proposition très maligne de faire ce que je dis, et d’utiliser mercurial (déja installé sur mon poste avec TortoiseHG) et hg-git. Bon, l’installation de hg-git dans TortoiseHG n’est pas immédiate, mais ça marche. J’ai donc cloné le repository, et lancé un brave

mvn install

Las ! les classes de test n’étaient pas à jour !
Enervé par tout ça, plutôt que de les corriger et de les envoyer à l’auteur, je les ai viré, et ça a marché. C’est alors que j’ai compris que l’auteur n’était en fait pas juste un jeune foufou, mais surtout une grosse feignasse : quand on commite alors que ça ne compile pas, on ne mérite pas d’être utilisé.
Bon, comme j’étais dedans jusqu’au coup, j’ai quand même utilisé sa librairie, mais le pire, c’est qu’elle est pleine de bugs !
Franchement, j’aurais mieux fait (et je vais peut-être finir par faire) un Builder Groovy pour Gephi, ça m’aurait évité bien des ennuis.
Parce que du coup, mon graphe, que j’espérais dynamique (et donc jouable comme un film Gource) ne l’est en fait pas du tout. Et ça, c’est vexant.

Et là, vous allez me demander pourquoi je m’énerve contre les DVCS.
Laissez-moi vous expliquer.
Avant, il y avait SVN et les forges. Si je voulais le source, c’était un peu compliqué.
Maintenant, avec hg et git (et surtout BitBucket et GitHub), c’est devenu hype de mettre son code sur le web et de laisser les gens cloner les dépôts; Du coup, les petits jeunes pleins d’envie psisent trois lignes de codes qui compilent à peu près, les mettent sur GitHub, et s’attendent à ce que l’utilisateur fasse tout l’effort pour que ça marche. Et bien je ne suis pas d’accord. Pour moi, la force de l’open-sourc, c’est le « release early, release often » dans lequel
on entend deux fois release, eUpdatet pas pour rien, à mon avis; releaser du code, c’est un acte fort : c’est dire aux gens qu’ils peuvent l’utiliser. Là, avec GitHub, j’ai l’impression qu’on se dirige de plus en plus vers un mode de fonctionnement où les gens crachent trois lignes et demi, et s’attendent à ce que les utilisateurs fassent à leur place le boulot d’industrialisation. C’est pas vraiment respectueux, je trouve.
Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s