La diver­si­té des ques­tions que se posent nos amis bio­lo­gistes entraîne une diver­si­té des don­nées : géno­miques, images, etc. De plus, ces don­nées sont géné­rées à des vitesses folles. Pour mani­pu­ler les don­nées et extraire les infor­ma­tions utiles, des solu­tions et outils bio­in­for­ma­tiques sont néces­saires. De nom­breux outils existent déjà pour répondre à de nom­breuses ques­tions. Mais par­fois, de nou­veaux outils sont néces­saires pour répondre à une ques­tion spé­ci­fique. Inter­vient alors le déve­lop­pe­ment d'un nou­vel outil bio­in­for­ma­tique.

Développer et distribuer un outil bioinformatique

Lorsque vous déve­lop­pez un outil bio­in­for­ma­tique, vous le faites dans le but pre­mier de répondre à une ques­tion. Une fois celle-ci cor­rec­te­ment for­mu­lée, vous choi­sis­sez votre méthode de tra­vail et les outils (1, 2) qui vous aide­rons à bien gérer votre pro­jet. Par exemple, si vous avez choi­si Java pour déve­lop­per votre pro­jet, il se peut que vous uti­li­siez Git comme ges­tion­naire de ver­sions et Maven comme ges­tion­naire de build.

Vous avez donc écrit du code source. Pour par­ta­ger votre solu­tion, vous allez écrire de la docu­men­ta­tion, faire de la for­ma­tion et du sup­port autour de l'outil. Et vous pou­vez être ame­né à le publier pour expli­quer votre méthode (sinon, ce n'est pas de la science repro­duc­tible, donc pas de la science, et tac !). Il vous faut alors dis­tri­buer votre pro­gramme. Cela peut être fait de bien des façons :

• en impri­mant le code (PDF) (Ceci est un troll)
• sous la forme d'un espace web dédié
• via une pla­te­forme de par­tage de code source, avec les ins­truc­tions pour uti­li­ser la solu­tion

Le par­tage des sources est pri­mor­dial pour assu­rer la trans­pa­rence, mais il peut être par­ti­cu­liè­re­ment dif­fi­cile d'installer cor­rec­te­ment un logi­ciel (mul­ti­tude de dépen­dances, incom­pa­ti­bi­li­té entre des ver­sions, etc). Le constat est simple : si votre algo­rithme est révo­lu­tion­naire mais que per­sonne ne peut l'utiliser, "je ne lui pré­dis pas un grand ave­nir" (#OSS117).

Cette voie fonc­tionne bien lorsque l'outil est simple et ne dépend pas de trop nom­breux autres outils. Cepen­dant, la phase de déploie­ment reste à la charge de l'utilisateur (ou de l'administrateur sys­tème du labo). Et le déploie­ment d'un logi­ciel est la proie de deux grands fléaux :

• les dépen­dances man­quantes (OHMYGOD!)
• les ver­sions des dépen­dances (I'MGONNADIE!!)

Il s'en suit alors un casse-tête dan­tesque où l'utilisateur doit ins­tal­ler impec­ca­ble­ment TOUTES les bonnes ver­sions de TOUTES les dépen­dances (si on peut encore les trou­ver et si elles sont com­pa­tibles avec son sys­tème, évi­dem­ment). A LA MAIN ! C'est évi­dem­ment une source colos­sale de fausse manip' et de décou­ra­ge­ment pour l'utilisateur, qui pré­fé­re­ra alors se tour­ner vers une solu­tion alter­na­tive.

Nous sommes donc face à un double pro­blème de dura­bi­li­té des outils et de leur déploie­ment. Ceux-ci ont des impacts impor­tants sur la pro­duc­ti­vi­té et la repro­duc­ti­bi­li­té en sciences. Il devient donc urgent de résoudre ces deux ques­tions et rendre la bio­in­for­ma­tique meilleure !

Faciliter le déploiement d'un logiciel

Les pro­blèmes pré­cé­dem­ment cités sont une chose que les uti­li­sa­teurs de sys­tèmes GNU/​Linux et OSX ne connaissent qu'à moi­tié, puisque rares sont ceux qui ins­tallent tout à la main. Le com­mun des mor­tels uti­lise, quand il le peut, un ges­tion­naire de paquets. Il en existent plu­sieurs étant pour la plu­part spé­ci­fique :

• à un lan­gage (pip pour Python, CPAN pour Perl, CRAN pour R, etc)
• à un sys­tème d'exploitation (yum pour Fedo­ra, APT pour Debian, howe­brew pour OSX, etc)

Le packa­ging demande un petit effort de la part du déve­lop­peur, mais le déploie­ment de l'outil der­rière le code est gran­de­ment faci­li­té. L'utilisateur n'a à se pré­oc­cu­per que de la par­tie "uti­li­sa­tion" (ce qui est somme toute plu­tôt logique). Pour que tout soit par­fait, il est éga­le­ment néces­saire de docu­men­ter le logi­ciel, de pro­po­ser des for­ma­tions, du sup­port et d'en faire la publi­ci­té.

La solution à tous nos maux : Conda

Pour qu'un outil soit uti­li­sé, il doit être faci­le­ment déployable n'importe où. Pour cela, il faut le packa­ger avec un ges­tion­naire de paquets qui soit :

• indé­pen­dant d'un lan­gage de pro­gram­ma­tion

Des outils bio­in­for­ma­tiques sont dis­po­nibles dans pra­ti­que­ment tous les lan­gages dis­po­nibles

• indé­pen­dant du sys­tème d'exploitation

Les outils sont uti­li­sés sur les prin­ci­paux sys­tèmes d'exploitation

• indé­pen­dant de pri­vi­lèges super uti­li­sa­teurs

Cer­tains uti­li­sa­teurs n'ont pas les droits d'administration de leur ordi­na­teur

• capable de gérer plu­sieurs ver­sions d'outils

Des ver­sions dif­fé­rentes d'un outil peuvent être requises par dif­fé­rents outils

• com­pa­tible avec une uti­li­sa­tion sur le Cloud ou en envi­ron­ne­ment HPC

Conda est un ges­tion­naire de paquets open-source qui répond très bien à ces pro­blé­ma­tiques. Bien que déve­lop­pé par la com­mu­nau­té PyDa­ta, conda est conçu pour gérer des paquets et dépen­dances de n'importe quel pro­gramme dans n'importe quel lan­gage. Conda est donc moins pip qu'une ver­sion mul­ti-sys­tème d'exploitation de apt et yum.

Un paquet conda est défi­ni par une recette et cor­res­pond in fine à un fichier tar­ball conte­nant des librai­ries au niveau sys­tème, Python ou d'autres modules, des pro­grammes exé­cu­tables ou d'autres com­po­sants. En dis­tri­buant des outils pré­com­pi­lés, l'installation de paquet conda est rapide, robuste et facile :

Il y a d'ailleurs un excellent article intro­duc­tif pour une ins­tal­la­tion et prise en main rapide de conda.

Les principales fonctionnalités de conda

Conda per­met donc de gérer dif­fé­rents logi­ciels, un peu à la manière de apt du point de vue de l'utilisateur. On retrouve les com­mandes sui­vantes :

Conda garde une trace des dépen­dances entre les paquets et les pla­te­formes. Par exemple, deeptools a besoin de python, numpy 1.9.0+ et scipy 0.17.0+ entre autres. Conda se charge d'installer ou de mettre à jour ses dépen­dances si besoin, ain­si que les dépen­dances de ces dépen­dances, etc.

Conda vient aus­si avec une ges­tion d'envi­ron­ne­ments vir­tuels, sur le même prin­cipe que les envi­ron­ne­ments vir­tuels de Python. Un envi­ron­ne­ment conda est un dos­sier conte­nant une col­lec­tion spé­ci­fique de paquets conda ins­tal­lés mais iso­lés des autres envi­ron­ne­ments conda. Ce prin­cipe per­met l'installation et la ges­tion de plu­sieurs ver­sions d'outils, comme Python 2.7 et Python 3.5 par exemple. Vous pou­vez alors créer des envi­ron­ne­ments dédiés qui assu­re­ront la repro­duc­ti­bi­li­té de vos ana­lyses. Tout est expli­quer ici pour créer vos envi­ron­ne­ments.

Encore des réti­cences vis-à-vis de Conda ? Je vous conseille de lire ce blog post sur les mythes et fausses idées liées à Conda.

Les channels

En bon ges­tion­naire de paquets, conda offre la pos­si­bi­li­té d'ajouter d'autres sources de paquets, aus­si appe­lées chan­nels. Les outils assez géné­ra­listes peuvent être trou­vé dans le chan­nel default ou conda-forge. Spé­cia­li­sé dans les outils bio­in­for­ma­tiques, le chan­nel Bio­con­da consiste en :

• Un dépôt GitHub de recettes
• Un sys­tème de construc­tion qui trans­forme ces recettes en paquets conda
• Un réper­toire de plus de 2 000 paquets bio­in­for­ma­tiques prêt à être uti­li­sés

Avec presque 200 contri­bu­teurs, cette com­mu­nau­té accueillante et for­mée il y a un peu plus de 1 an gros­sit rapi­de­ment. Elle ajoute, modi­fie, met à jour et main­tient les nom­breuses recettes des paquets conda d'outils bio­in­for­ma­tiques exis­tant, mais vous don­ne­ra aus­si tout un tas de conseils pour par­faire vos recettes.

Packager un logiciel

Envie d'écrire un paquet conda pour un outil exis­tant ? On pour­rait pen­ser que cela est dif­fi­cile étant don­nés les avan­tages appor­tés par conda. Mais au contraire, l'écriture de paquets conda a été pen­sée pour être facile et per­mettre ain­si à tous d'intégrer les outils dans conda avec une docu­men­ta­tion exten­sive. Ain­si, un paquet conda consiste en deux fichiers :

• Un fichier meta.yaml conte­nant les méta-don­nées du paquet : le nom, la ver­sion, où trou­ver les sources, les dépen­dances de l'outil, …
• Un fichier build.sh pour expli­quer com­ment conda doit créer le paquet

Par exemple, pour le logi­ciel deep­tools, on le fichier meta.yaml sui­vant :

Cette recette fera auto­ma­ti­que­ment appel au script build.sh qui contient les ins­truc­tions pour ins­tal­ler le logi­ciel, en l’occurrence :

Bio­con­da pro­pose un guide pour écrire des recettes qui seront par la suite inté­grées au chan­nel. Et dans tous les cas, vous pou­vez faire appel aux membres de la com­mu­nau­tés pour vous aider à construire, débug­ger, mettre à jour ou par­faire votre recette.

Bioconda va même encore plus loin !

Pour faci­li­ter le déploie­ment tout en sui­vant les besoins évo­qués pré­cé­dem­ment, un autre moyen de packa­ger un outil est de le contai­ne­ri­ser. La contai­ne­ri­sa­tion la plus connue est Docker, mais il existe d'autres solu­tions comme rkt ou Sin­gu­la­ri­ty. Ces contai­ners per­mettent d'obtenir un plus haut niveau d'abstraction pour un outil par rap­port au sys­tème de base.

La créa­tion de contai­ners pour un outil est plus com­plexe que pour créer un paquet conda. Par exemple, pour créer un contai­ner Docker, il faut créer un fichier Docker­file décri­vant l'image de base uti­li­sée, les com­mandes pour créer l'outil, etc.

Mul­led est un pro­jet per­met­tant de géné­rer un contai­ner (Bio­Con­tai­ner) mini­mal pour Docker ou rkt à par­tir d'un paquet conda, alpine or linux­brew. Il faut seule­ment ajou­ter une ligne dans un fichier TSV pour indi­quer à Mul­led de créer le contai­ner.

Pour des paquets Bio­con­da, c'est encore plus facile : il n'y a rien à faire. Mul­led par­court tous les paquets Bio­con­da quo­ti­dien­ne­ment et génère des Bio­Con­tai­ners auto­ma­ti­que­ment pour tous les paquets Bio­con­da.

En packa­geant les outils avec conda au sein de Bio­con­da, on réduit dras­ti­que­ment le pro­blème de déploie­ment des outils aux uti­li­sa­teurs. Les outils deviennent faci­le­ment déployables avec plu­sieurs solu­tions : via les paquets conda ou via des Bio­Con­tai­ners construits auto­ma­ti­que­ment.

La durabilité et disponibilité

Un outil peut dépendre de nom­breux autres outils, qui peuvent ne plus être main­te­nus ni même dis­po­nibles. L'indisponibilité des outils posent de nom­breux pro­blèmes dont ceux de repro­duc­ti­bi­li­té et dura­bi­li­té.

Pour résoudre ces pro­blèmes, l'idéal serait d'avoir un sto­ckage per­ma­nent de toutes les ver­sions des paquets et outils uti­li­sés pour qu'ils soient tou­jours acces­sibles.

La repro­duc­ti­bi­li­té et l'accessibilité font par­tis des man­tras du pro­jet Galaxy. Ain­si, pour répondre aux pro­blèmes de dis­po­ni­bi­li­té et de dura­bi­li­té des outils et paquets, la com­mu­nau­té autour de Galaxy a mis en place Car­go Port, un réper­toire public pour archi­ver de nom­breux paquets de façon stable et per­ma­nente.

Ajou­ter un paquet dans ce dépôt est facile. Il suf­fit d'ajouter une ligne dans un fichier TSV avec les infor­ma­tions (nom et URL) sur le paquet à sto­cker. Pour les paquets créés avec Bio­con­da, c'est même encore plus facile : il n'y a rien à faire ! Car­go Port fait des archives jour­na­lières des recettes et paquets Bio­con­da, et per­met ain­si de résoudre les pro­blèmes de dura­bi­li­té et dis­po­ni­bi­li­té des outils.

Déploiement et durabilité des outils en bioinformatique : Fixés !

Le déve­lop­pe­ment des paquets Bio­con­da est très facile et faci­lite le packa­ging et le déploie­ment de tout outil bio­in­for­ma­tique. Avec le pro­jet Mul­led, des contai­ners GNU/​Linux effi­caces sont auto­ma­ti­que­ment construits pour tous paquets Bio­con­da pour per­mettre un plus haut niveau d'abstraction et d'isolation par rap­port au sys­tème de base. C'est un super effort de dif­fé­rentes com­mu­nau­tés pour créer un sys­tème flexible et exten­sible et fixer ain­si le pro­blème de déploie­ment une fois pour toute.

L'interface avec paquets Bio­con­da avec Car­go Port amé­liore la dis­po­ni­bi­li­té et la dura­bi­li­té en conser­vant toutes les sources.

Nous espé­rons vous avoir convain­cus que grâce à ces pro­jets col­la­bo­ra­tifs, leur com­mu­nau­té et leurs col­la­bo­ra­tions, les outils bio­in­for­ma­tiques peuvent être faci­le­ment packa­gés et être tou­jours dis­po­nibles pour leurs uti­li­sa­teurs. La seule chose à faire est de créer une recette Bio­con­da et rendre ain­si vos uti­li­sa­teurs heu­reux et leurs (et vos) ana­lyses effi­caces et repro­duc­tibles !

---

Mer­ci à Nico M, Hed­Jour, Mathu­rin, Aki­ra pour les relec­tures et les com­men­taires inté­res­sants !

Cet article a été écrit conjoin­te­ment par Béré­nice et Kévin