Nextflow, pour votre prochain pipeline ?

Pour commencer

Vous savez déjà tout sur les pipe­lines et les bonnes pra­tiques de déve­lop­pe­ment. Vous faites bien évi­dem­ment de la recherche repro­duc­tive. Vous tra­vaillez peut-être avec un clus­ter. Vous avez écrit votre propre pipe­line en Bash, Python ou même en Perl qui gérait les appels à dif­fé­rents scripts et outils (voire même l'appel à l'ordonnanceur). Vous déve­lop­pez un pipe­line, ou le main­te­nez. Vous êtes inté­res­sé par la décou­verte de nou­veaux outils. Vous avez vu la lumière et vous êtes entrés. Bref, cet article est là pour vous.

Ma petite expérience

C'est un grand clas­sique de réin­ven­ter la roue, et je pense pou­voir affir­mer sans me trom­per qu'on a tous ten­té de le faire à un moment ou à un autre. Dans mon cas je n'ai mal­heu­reu­se­ment décou­vert Make que sur le tard, et n'ai com­men­cé à m'en ser­vir que pour com­pi­ler ma thèse sous LaTeX (et depuis chaque docu­ment LaTeX). Mais déjà je savais que le pro­chain pipe­line ne serait pas fait à la main. Pro­ba­ble­ment en uti­li­sant Make, car il me parle d'aventures. Je me suis long­temps posé aus­si la ques­tion de Sna­ke­make. Et puis nou­veau bou­lot, nou­veau pou­voir pro­jet, et c'est donc Next­flow qui a été choi­si pour déve­lop­per le pipe­line. Donc je n'ai que peu d'expérience avec Make, aucune avec Sna­ke­make. Mais ayant décou­vert Next­flow, je vais donc ten­ter de vous le pré­sen­ter et d'expliquer ce qui m'a plu dans ce fra­me­work.

La philosophie

Next­flow est basé sur un modèle de pro­gram­ma­tion orien­té en flux de don­nées et deux concepts clés : Pro­cess et Chan­nel. En plus clair, ce sont les don­nées qui contrôlent le pipe­line. Le Pro­cess est le pro­ces­sus de base qui va exé­cu­ter un script. Pour chaque Pro­cess, on peut défi­nir un Input et un Out­put (entrée/​sortie). Ces Inputs/​Out­puts peuvent être une valeur, un fichier, un ensemble de valeurs et/​ou fichiers, ou plu­sieurs fichiers, valeurs et ensembles. Les dif­fé­rents Pro­cesses com­mu­niquent au moyen de Chan­nel (Chaque Input/​Out­put de votre Pro­cess est en fait une Chan­nel). Ces der­nières sont uti­li­sées pour faire les mani­pu­la­tions sur les don­nées, qu'elles soient valeurs ou fichiers.
Et c'est tout.

La magie

Vous êtes plu­tôt Python ou plu­tôt Perl ? Pas de sou­cis, pour chaque Pro­cess, vous pou­vez direc­te­ment écrire vos scripts dans le lan­gage que vous dési­rez (même R…). Ou les lignes de com­mandes en Bash pour appe­ler les scripts. Pas besoin de spé­ci­fier les liens entre les dif­fé­rents Pro­cesses, Next­flow s'en occupe, grâce au nom de la Chan­nel (l'Out­put d'un Pro­cess est l'Input d'un autre). Paral­lé­li­ser votre code ? Pas de pro­blème, c'est impli­cite avec Next­flow. Il suf­fit juste de défi­nir vos Inputs et Out­puts, Next­flow se charge de paral­lé­li­ser l’exécution. Vous bos­sez sur dif­fé­rentes machines, Next­flow four­nit une couche entre le pipe­line et l'exécution, et s'en occupe, que ce soit sur un clus­ter, ou un ordi clas­sique. Next­flow se charge bien évi­dem­ment de lan­cer les dif­fé­rents Pro­cesses au fur et à mesure. Pas besoin d'adapter votre code à votre machine… Vous vou­lez un café pen­dant que vos scripts tournent, bon là par contre il va fal­loir le faire vous même… (enfin sauf si vous avez un script pour votre machine à café), par contre aucun sou­ci pour une poké­pause.

Reproductibilité

Tous les résul­tats inter­mé­diaires sont auto­ma­ti­que­ment enre­gis­trés, il est donc facile de recom­men­cer à par­tir de la der­nière étape réus­sie. Il est pos­sible d'avoir les temps d'exécution (et d'occupation de la mémoire) pour cha­cun des Pro­cesses (avec les para­mètres -with-trace et/​ou -with-time­line). Chaque Pro­cess est auto­ma­ti­que­ment enre­gis­tré, et on peut donc retrou­ver les dif­fé­rentes étapes, et appels à cha­cun des scripts, variables d’environnement, ver­sion des outils et pro­grammes uti­li­sés… Vous pou­vez aus­si faci­le­ment auto­ma­ti­ser une ges­tion des erreurs, et relan­cer auto­ma­ti­que­ment un Pro­cess (qui par exemple aurait échoué faute de mémoire tout en lui allouant plus de mémoire/​CPU pour un essai sui­vant (et limi­ter le nombre d'essais par la même occa­sion)). Si votre code est ver­sion­né avec Git, vous pou­vez lan­cer une ver­sion en par­ti­cu­lier de votre pipe­line avec un simple para­mètre -r nom­de­la­ver­sion, ce qui vous assure d'utiliser le même code. Next­flow sup­porte nati­ve­ment Docker, et vous pou­vez donc uti­li­ser un contai­ner pour pou­voir englo­ber tout ce qu'il vous faut.

Un exemple ?

De très bons exemples se trouvent sur inter­net, et donc même si j'aime bien refaire la roue, je vais juste en expli­quer un.

Pour le faire mar­cher, il suf­fit juste d'installer Next­flow, de télé­char­ger le fichier sample.fa et de créer votre script monS​cript​.nf dans votre édi­teur de texte pré­fé­ré. Un simple :

Partage et Cloud

Next­flow est très faci­le­ment par­ta­geable, et vous pou­vez direc­te­ment exé­cu­ter un script Next­flow se trou­vant sur Github :

Une communauté active

Pao­lo Di Tom­ma­so, le lead dev sur Next­flow est hyper réac­tif, que ce soit sur le chat Git­ter, ou le Google group. Un cer­tain nombre de pipe­lines sont éga­le­ment awe­so­me­ment lis­tés sur GitHub, c'est une très bonne source d'inspiration.

Pourquoi Nextflow ?

Plu­sieurs se sont déjà posé la ques­tion de quel fra­me­work uti­li­ser pour gérer un pipe­line, ici aus­si. Julian Maz­zi­tel­li a fait une com­pa­rai­son entre Bash, Make, Sna­ke­Make et Next­flow dans un article de blog que je conseille de lire. Dans notre groupe la déci­sion finale était entre Sna­ke­Make et Next­flow. Et comme dit pré­cé­dem­ment, ça c'est déci­dé sur Next­flow pour mon pro­jet.

Inconvénients

Écrit en Groo­vy, et même si cer­tains diront que Groo­vy n'aurait jamais du exis­ter (notam­ment James Stra­chan l'un des créa­teurs), per­son­nel­le­ment le seul incon­vé­nient que j'ai ren­con­tré a été de devoir apprendre une nou­velle syn­taxe, et je n'ai pas eu trop de mal à m'y faire. Je trouve à mon humble avis que ça reste moins obs­cur qu'un Make­file.

Conflits d'intérêts

Aucun.

Remerciements

Je remer­cie Yoann M. pour sa moti­va­tion concer­nant cet article, Estel pour m'avoir redon­né la moti­va­tion de réécrire des articles, ain­si que Lelouar, _​NiGoPol_​ et Norore bien aimés relec­teurs pour leurs avis et dis­cus­sions.