SciFigWorkflow : générer ses figures sans peine
Il y a un an, je racontais comment je gérais mes figures. C’est le moment de faire le point. J’ai beaucoup utilisé ces scripts pour produire mes figures et je dois dire que je pense être parvenu à une mécanique correcte.
Je parle au passé parce que les choses ont encore évolué un peu, c’est ce qui justifie un nouveau billet. La méthode fonctionne bien, l’implémentation un peu moins. J’utilisais des scripts (langages variés : bash, perl…) et des Makefiles écrits à la main pour l’automatisation. C’est très bien pour la preuve du concept, mais en qui concerne maintenabilité ce n’était pas tout à fait à mon goût. Bash n’est plus depuis longtemps mon langage favori de scripts et Makefile, je dois ressortir des pense-bêtes à chaque fois que je veux l’éditer pour peu qu’il y ait des passages illisibles concis. Un langage unique et clair serait un bénéfice donc.
Autre point, les sources et les cibles étaient produites dans les même répertoires. Ca devient vite chaotique même si je pouvais faire un « make clean ». Il existait peut-être une couche à Makefile pour faire ça, mais ça ne me tentait pas trop.
J’ai donc décidé de tout remettre à plat et j’ai découvert waf. Waf est un outil de build écrit en python relativement simple à prendre en main (je ne dirai pas que c’est facile non plus, une bonne doc existe cependant). Du coup, les scripts sont à écrire en python que je maitrise à peu près et qui a le bon goût d’avoir une syntaxe lisible.
Cette nouvelle implémentation me donne la sensation d’avoir un véritable workflow. Il est puissant, rapide et je sais que je peux ajouter des briques facilement. Typiquement, si je devais remplacer gnuplot par une lib d’optimisation + lib graphique, je pense qu’une dizaine de lignes suffirait à adapter mon workflow. Outre la compilation dans un répertoire de « build », je peux installer les figures compilées là où je le souhaite (au hasard, mon document latex).
Ce que je tire de tout ça : un gain d’efficacité énorme. Mes figures sont bien rangées dans un répertoire source, je les édite avec un simple éditeur texte (ça tombe bien, j’ai ça quand je rédige un document !), je compile en quelques frappes. Ainsi quand je rédige mon document et que je me rend compte que l’étiquette du graphique n’est pas bonne, je corrige le problème en 20 secondes, là où l’absence du workflow et de ce choix technologique aurait nécessité quelques minutes. En effet, certains doivent ouvrir un logiciel tiers, éditer la figure, exporter sous le bon format, dans le bon répertoire… si on retrouve la source de la figure. Je souhaite aussi faire remarquer que le fait de n’avoir aucune étape manuelle dans la création des figures assure la reproductibilité. Je connais de nombreuses personnes utiliser des logiciels comme adobe illustrator, ce serait pour moi dramatique de devoir me souvenir et refaire sans cesse les même modifications alors que j’ai une machine puissante de calcul à mes pieds, douée pour ça !
Mon code mis en partage ici : https://github.com/sciunto/SciFigWorkflow
Par ailleurs, j’ai présenté un poster sur ce projet lors de Euroscipy2012. Le poster se trouve dans le dépôt.
Je pratique le « release soon, release often ». J’ai amélioré la doc et le code ces derniers temps, mais du travail reste à faire même si je l’utilise déjà en prod pour une grande partie de mes figures. Vous êtes prévenus Comme j’ai de nombreuses idées de code à réaliser, ça bouge lentement.
J’insiste par ailleurs sur le fait que mon workflow n’est probablement pas le votre. Il a pour ambition de répondre à mes besoins. Ce que je souhaite, c’est partager l’idée et mettre en avant l’importance et la difficulté du choix technologique pour avoir un workflow malléable.
Lors de discussions à Euroscipy, j’ai évoqué quelques idées que j’ai derrière la tête avec tout ça. Je ne vais pas me censurer ici. A terme, je souhaite étendre mon workflow à quelque chose de plus global. Pour l’instant, il ne travaille que sur des données « prêtes à l’emploi ». Je souhaite ajouter de nouvelles couches pour que le traitement de données et la production des figures fassent parti d’une suite logique. Cette volonté va de paire avec mon intérêt pour l’open data car je pense que l’ouverture des données scientifiques est quelque chose de difficile et coûteux en temps et qu’il est nécessaire de s’y préparer. Le but étant de donner le plus possible de données pour pouvoir « rejouer le process » qui a conduit aux résultats. Idée à laisser mûrir.