Pourquoi et comment déposer un package R sur Bioconductor ?

Ça y est, votre code R un poil brut com­mence à avoir de la sub­stance et vous envi­sa­gez d'en faire un outil à part entière. Comme tout bio­in­for­ma­ti­cien qui se res­pecte, vous envi­sa­gez donc de packa­ger (ou paque­ter en fran­çais) pro­pre­ment cet ensemble de scripts R.

Non on ne largue pas une nuée de scripts non com­men­tés, non docu­men­tés, avec juste un mail disant "Non mais tu changes tel et tel para­mètres et ça fonc­tionne"…

Quand j'essaie d'expliquer le concept de repro­duc­ti­bi­li­té à un mau­vais bio­in­for­ma­ti­cien

Votre package R étant évi­dem­ment d'une grande uti­li­té à la com­mu­nau­té bio­in­for­ma­tique, vous envi­sa­gez de le par­ta­ger. La ques­tion du réper­toire de packages où vous le dépo­se­rez une fois fini va donc se poser, et avec, les condi­tions de déve­lop­pe­ment du package qui s'appliqueront.

Pourquoi déposer son package sur Bioconductor alors qu'il y a le CRAN ?

Le CRAN (pour Com­pre­hen­sive R Archive Net­work) est évi­dem­ment LE réper­toire de packages R. Il cen­tra­lise bon nombre d'entre eux, tou­chant à des domaines variés : sta­tis­tiques, phy­sique, mathé­ma­tiques, psy­cho­lo­gie, éco­lo­gie, visua­li­sa­tions, machine lear­ning, car­to­gra­phie, …, et bio­in­for­ma­tique. Cepen­dant à avoir autant de varié­té, on s'y perd. C'est pour­quoi Bio­con­duc­tor a en par­tie été créé.

Bio­con­duc­tor c'est un réper­toire alter­na­tif de packages R spé­ci­fi­que­ment dédié à la bio­in­for­ma­tique créé en 2002. Aki­ra vous le pré­sen­tait en 2012 sur le blog, et huit ans plus tard, force est de consta­ter que le pro­jet tient tou­jours, et même prend de l'ampleur (cf. Figure 1). La voca­tion est res­tée la même : regrou­per sous une même ban­nière des packages spé­ci­fiques à la bio­in­for­ma­tique, et notam­ment à l'analyse et la com­pré­hen­sion de don­nées de séquen­çage haut débit.

L'avantage, c'est que la visi­bi­li­té de votre package est aug­men­tée au sein de la com­mu­nau­té bioin­fo. Et au-delà du simple réper­toire, c'est éga­le­ment une com­mu­nau­té par­ti­cu­liè­re­ment active qui s'y rat­tache, avec un sys­tème à la Sta­ckO­ver­flow.

Mais est-ce inté­res­sant pour autant dans votre cas ? Car tout le monde n'a pas inté­rêt et ne peut pas dépo­ser dans Bio­con­duc­tor.

Comment savoir si on doit déposer son package dans le CRAN ou Biocondutor ?

Alors pour­quoi avoir fait ce réper­toire plu­tôt que d'avoir tout mis dans le CRAN ? Et com­ment choi­sir où votre package doit être dépo­sé ? Quelques élé­ments pour vous aider :

• Comme dit plus haut, Bio­con­duc­tor est spé­cia­li­sé en package pour la bio­in­for­ma­tique. Donc si vous déve­lop­pez un package avec des méthodes géné­ra­listes comme dplyr ou spé­cia­li­sées dans d'autres domaines comme eco­dist en éco­lo­gie, visez plu­tôt le CRAN.
• À l'inverse, si vous impor­tez dans votre package d'autres package qui pro­viennent de Bio­con­duc­tor, visez plu­tôt un dépôt sur celui-ci.
• Si vous êtes prêts à assu­rer un sup­port à long terme, notam­ment en répon­dant aux ques­tions sur votre package, diri­gez-vous vers Bio­con­duc­tor. Sinon visez le CRAN.
• Si vous sou­hai­tez une publi­ca­tion "en pro­duc­tion" rapide de votre package, visez le CRAN. En effet Bio­con­duc­tor fonc­tionne avec un sys­tème de release (publi­ca­tion) bis­an­nuelle (une en avril, et une en octobre). Vous avez cepen­dant accès à une branche dites de déve­lop­pe­ment en atten­dant la release, la bioc-devel. Sachez tout de même qu'on a déjà vu des articles sor­tir avec un lien vers cette branche. La branche de pro­duc­tion ne semble donc pas être une obli­ga­tion pour publier son article même si c'est recom­man­dé (ques­tion de sta­bi­li­té).
• Le CRAN est en droit de dépré­cier un package car il ne convient pas avec la nou­velle release de R (en vous met­tant au cou­rant quelques semaines au plus avant de le faire). Bio­con­duc­tor pos­sède une plus grande sou­plesse sur ce point : si vous vous assu­rez qu'il fonc­tionne pour chaque release, il est peu pro­bable qu'il soit dépré­cié.
• Si vous avez envie de ne pas pas­ser les tests qui cassent les gonades de Bio­con­duc­tor, allez sur le CRAN

Évi­dem­ment, vous trou­ve­rez des packages de bio­in­for­ma­tique sur le CRAN éga­le­ment (ex : WGCNA), mais c'est là une occa­sion de man­quer de visi­bi­li­té au sein de notre com­mu­nau­té. À savoir éga­le­ment que rien n'est gra­vé dans le marbre. La preuve avec le package mixO­mics qui était ini­tia­le­ment sur le CRAN mais a été dépla­cé sur Bio­con­duc­tor il y a un peu plus d'un an !

J'ai choisi, ce sera Bioconductor ! Mais comment ça se passe ?

Féli­ci­ta­tions ! Mais atten­dez-vous à un che­min pavé d’embûches et assez éprou­vant, je ne vais pas vous men­tir. Une fois fini, vous ver­rez que le jeu en vaut la chan­delle.

Note :

• Si vous avez déjà sou­mis un package sur le CRAN, sau­tez direc­te­ment à la sec­tion Les pré­re­quis spé­ci­fiques à Bio­con­duc­tor 😉
• Si vous n'avez jamais déve­lop­pé de package R, lais­sez-moi un com­men­taire comme quoi ça vous inté­resse. J'y consa­cre­rai alors un autre billet de blog. En atten­dant, je vous laisse suivre ce très bon tuto­riel pour apprendre (ou bien lire le manuel du CRAN si vous avez un côté maso… puriste).

Ima­gi­nons à pré­sent que vous avez (ou pen­sez avoir) ter­mi­né votre package appe­lé, de façon très ori­gi­nale, mypkg. Il va fal­loir pas­ser par plu­sieurs phases de pré-sou­mis­sion.

Le tronc commun avec le CRAN

Pour vous assu­rer que votre package soit par­ta­geable à la com­mu­nau­té, il est néces­saire de res­pec­ter cer­taines bonnes pra­tiques, ain­si que de s'assurer qu'il soit exé­cu­table par d'autres. Et en concret, com­ment on teste ça ?

Com­men­çons par la com­pi­la­tion de votre package, ou build. Si vos fonc­tions tournent sans pro­blème lorsque vous les exé­cu­tez à la main hors de votre package, il n'est pas assu­ré que celui-ci fonc­tionne en tant que tel pour autant !

Deux choix s'offrent alors à vous quant à la façon de pro­cé­der :

• Vous êtes un accro du shell et de R sans IDE ? Il vous fau­dra faire rou­ler dans votre shell la com­mande R CMD ins­tall. Exemple : R CMD install /home/bioinfofr/dev/R/mypkg
• Vous aimez bien Rstu­dio et avoir un coup de pouce ? Le package dev­tools est fait pour vous. C'est lui qui est uti­li­sé der­rière les bou­tons de build de Rstu­dio. Ren­dez-vous dans cet onglet comme en Figure 2 et cli­quez sur Build Source Package.

Si tout se passe bien, vous devriez avoir ce genre de rap­port :

[1] "/home/bioinfofr/dev/R/mypkg_0.99.99.tar.gz"

Source package writ­ten to ~/​dev/​R

Et sinon… Eh bien les mes­sages d'erreurs sont plu­tôt expli­cites sur la source du pro­blème. Le plus sou­vent vous aurez sim­ple­ment mal res­pec­té l'architecture d'un package R (un dos­sier mal nom­mé, des fichiers qui traînent, etc.) ou des infor­ma­tions man­quantes dans le fichier DESCRIPTION.

Une fois que votre package est com­pi­lé, pas­sons aux checks (véri­fi­ca­tions) auto­ma­tiques. À nou­veau, deux choix s'offrent à vous :

• En shell : Il vous fau­dra faire rou­ler la com­mande R CMD check. Exemple : R CMD check /home/bioinfofr/dev/R/mypkg
• Avec Rstudio/​devtools : ren­dez-vous dans l'onglet build comme en Figure 3 et cli­quez sur Check. Cela lance la fonc­tion devtools::check().

Une fois ter­mi­né, voi­ci le genre de rap­port que vous devriez obte­nir :

── Che­cking ──────────────────────────────────── mypkg ──
Set­ting env vars :
● _​R_​CHECK_​CRAN_​INCOMING_​USE_​ASPELL_​ : TRUE
● _​R_​CHECK_​CRAN_​INCOMING_​REMOTE_​ : FALSE
● _​R_​CHECK_​CRAN_​INCOMING_​ : FALSE
● _​R_​CHECK_​FORCE_​SUGGESTS_​ : FALSE
● NOT_​CRAN : true
── R CMD check ─────────────────────────────────────────────────────────────────
─ using log direc­to­ry ‘/home/bioinfofr/dev/R/mypkg/mypkg.Rcheck’ (517ms)
─ using R ver­sion 4.0.0 (2020–04-24)
─ using plat­form : x86_64-pc-linux-gnu (64-bit)
─ using ses­sion char­set : UTF‑8
─ using options ‘–no-manual –as-cran’ (692ms)
✓ che­cking for file ‘mypkg/​DESCRIPTION’
─ this is package ‘mypkg’ ver­sion ‘0.99.99’
─ package enco­ding : UTF‑8
✓ che­cking package names­pace infor­ma­tion …
✓ che­cking package depen­den­cies (6.5s)
✓ che­cking if this is a source package
✓ che­cking if there is a names­pace
✓ che­cking for exe­cu­table files (510ms)
✓ che­cking for hid­den files and direc­to­ries
✓ che­cking for por­table file names …
✓ che­cking for sufficient/​correct file per­mis­sions
✓ che­cking whe­ther package ‘mypkg’ can be ins­tal­led (24.9s)
N che­cking ins­tal­led package size …
ins­tal­led size is 10.2Mb
sub-direc­to­ries of 1Mb or more :
data 5.6Mb
doc 4.1Mb
✓ che­cking package direc­to­ry …
✓ che­cking for future file times­tamps (1.1s)
✓ che­cking ‘build’ direc­to­ry
✓ che­cking DESCRIPTION meta-infor­ma­tion …
✓ che­cking top-level files
✓ che­cking for left-over files
✓ che­cking index infor­ma­tion …
✓ che­cking package sub­di­rec­to­ries …
✓ che­cking R files for non-ASCII cha­rac­ters …
✓ che­cking R files for syn­tax errors …
✓ che­cking whe­ther the package can be loa­ded (8s)
✓ che­cking whe­ther the package can be loa­ded with sta­ted depen­den­cies (7.9s)
✓ che­cking whe­ther the package can be unloa­ded clean­ly (7.3s)
✓ che­cking whe­ther the names­pace can be loa­ded with sta­ted depen­den­cies (7.4s)
✓ che­cking whe­ther the names­pace can be unloa­ded clean­ly (7.6s)
✓ che­cking loa­ding without being on the libra­ry search path (7.6s)
✓ che­cking depen­den­cies in R code (7.1s)
✓ che­cking S3 generic/​method consis­ten­cy (10.2s)
✓ che­cking repla­ce­ment func­tions (7.2s)
✓ che­cking forei­gn func­tion calls (7.4s)
✓ che­cking R code for pos­sible pro­blems (26s)
✓ che­cking Rd files (339ms)
✓ che­cking Rd meta­da­ta …
✓ che­cking Rd line widths …
✓ che­cking Rd cross-refe­rences …
✓ che­cking for mis­sing docu­men­ta­tion entries (7.9s)
✓ che­cking for code/​documentation mis­matches (23.6s)
✓ che­cking Rd usage sec­tions (9.6s)
✓ che­cking Rd contents …
✓ che­cking for uns­ta­ted depen­den­cies in examples …
✓ che­cking contents of ‘data’ direc­to­ry (380ms)
✓ che­cking data for non-ASCII cha­rac­ters (657ms)
✓ che­cking data for ASCII and uncom­pres­sed saves …
✓ che­cking ins­tal­led files from ‘inst/​doc’ …
✓ che­cking files in ‘vignettes’ …
✓ che­cking examples (1m 21.8s)
Examples with CPU (user + sys­tem) or elap­sed time > 5s
user sys­tem elap­sed
my_​foo_​one 17.875 0.191 11.064
my_​foo_​two 1.468 0.032 10.086
my_​foo_​de_​vous 0.152 0.004 24.143
my_​foo_​foo_​ne 0.022 0.004 7.865
✓ che­cking for uns­ta­ted depen­den­cies in vignettes …
✓ che­cking package vignettes in ‘inst/​doc’ …
✓ che­cking re-buil­ding of vignette out­puts (1m 47.3s)
✓ che­cking for non-stan­dard things in the check direc­to­ry
✓ che­cking for detri­tus in the temp direc­to­ry

See
‘/home/bioinfofr/dev/R/mypkg/mypkg.Rcheck/00check.log’
for details.

── R CMD check results ────────────────────────────────────── mypkg 0.99.99 ────
Dura­tion : 6m 14.2s

> che­cking ins­tal­led package size … NOTE
ins­tal­led size is 10.2Mb
sub-direc­to­ries of 1Mb or more :
data 5.6Mb
doc 4.1Mb

0 errors ✓ | 0 war­nings ✓ | 1 notes x

R CMD check suc­cee­ded

Comme vous le voyez, le risque d'erreurs/avertissements est assez grand (trop grand pour que je couvre ici tous les cas !). Mais ras­su­rez-vous, per­sonne ne pense à tout dès la pre­mière fois qu'il déve­loppe son package. Vous fini­rez donc irré­mé­dia­ble­ment avec des cor­rec­tions à faire, car pour pou­voir sou­mettre votre package, vous ne devez avoir aucune ERROR ou WARNING. La meilleure pra­tique pour évi­ter d'avoir des dizaines de cor­rec­tions à faire, c'est de tes­ter le build et exé­cu­ter les checks régu­liè­re­ment dans votre pro­ces­sus de déve­lop­pe­ment (ça vous évi­te­ra de devoir reco­der des pans entiers de votre outil car l'erreur vient d'un bout de code sur lequel s'appuient d'autres). Pen­sez éga­le­ment à mettre à jour les packages sur votre poste local car ce sont les der­nières ver­sion de ceux-ci qui seront uti­li­sées par le CRAN pour rou­ler les checks de leur côté (et pareil pour Bio­con­duc­tor).

Les NOTEs sont quant à elles tolé­rées dans une cer­taine mesure, et cette mesure est à la dis­cré­tion de la per­sonne qui fera la relec­ture cri­tique de votre package (mais comme nous allons viser Bio­con­duc­tor dans cet article, ce sont d'autres revie­wers encore que ceux du CRAN).

Les prérequis spécifiques à Bioconductor

Vous avez tous vos checks qui passent ? Bien joué. Mais il va encore vous fal­loir pas­ser ceux de Bio­con­duc­tor ! Et c'est pas gagné.

Bio­con­duc­tor est encore plus res­tric­tif que le CRAN sur ses tests appe­lés Bioc­Check. En effet, ils ont défi­ni tout un ensemble de bonnes pra­tiques sup­plé­men­taires liées à la fois aux spé­ci­fi­ci­tés bio­in­for­ma­tiques, à la lisi­bi­li­té du code, à des recom­man­da­tions sur l'utilisation de telle ou telle façon de coder. Si cer­tains de leurs par­tis pris sont dis­cu­tables, il n'en reste pas moins que vous allez devoir vous y sou­mettre.

À défaut de vous les lis­ter tous, je vais vous indi­quer le mini­mum à res­pec­ter pour vous évi­ter masse de chan­ge­ment. L'idéal reste tout de même de les lire avant de com­men­cer à déve­lop­per votre package, car cer­tains vont for­te­ment impac­ter votre package.

• Il va fal­loir défi­nir à quelle caté­go­rie votre package appar­tient : Soft­ware, Expe­riment Data, ou Anno­ta­tion. La pre­mière est celle regrou­pant les outils d'analyse à pro­pre­ment dit. Les deux der­nières sont des packages de don­nées aux noms assez expli­cites quant à leur conte­nu.
• Si votre package uti­lise des don­nées clas­siques en bioin­fo (matrices gènes X échan­tillons, FASTA, VCF, spec­tro de masse, etc.) sachez que vous devrez au moins rendre com­pa­tible votre package avec les com­mon classes de Bio­con­duc­tor. Ces for­mats sont une ten­ta­tive de stan­dar­di­sa­tion de l'input dans les packages de ce dépôt.
• Si c'est un Soft­ware, votre package final devra faire moins de 5Mo. Atten­tion donc aux jeux de don­nées d'exemple que vous insé­rez dedans. Si jamais vous sou­hai­tez inclure des don­nées plus grosses, on vous conseille de sou­mettre un autre package de type Expe­riment Data, ou Anno­ta­tion et de l'appeler dans votre package.
• Il devra être com­pa­tible Linux ET Win­dows ! Mau­vaise idée donc de se baser sur des spé­ci­fi­ci­tés de votre OS. Ou alors pré­pa­rez-vous à devoir déve­lop­per un équi­valent dans l'autre OS.
• Toutes vos fonctions/​données doivent être docu­men­tées ! Et pas seule­ment avec une rapide des­crip­tion. On parle d'une expli­ca­tion des para­mètres, d'une valeur retour, et sur­tout d'un exemple exé­cu­table fonc­tion­nel.
• Il fau­dra écrire une vignette, ce docu­ment fai­sant office d'introduction à votre package et de tuto­riel. Il est néces­saire qu'on passe à tra­vers un maxi­mum des fonc­tion­na­li­tés de votre package, l'idéal étant d'y réa­li­ser une ana­lyse type, sur de véri­tables don­nées ou des don­nées simu­lées.
• Les tests uni­taires ne sont pas obli­ga­toires d'après leur gui­de­lines, mais soyez assu­rés qu'ils vous les deman­de­ront tout de même pour la majo­ri­té de vos fonc­tions au moment de la revue. Mais en tant que bio­in­for­ma­ti­cien conscien­cieux vous les auriez déjà faits n'est-ce pas 😉 ?
• Vous devez être ins­crits au site de sup­port de Bio­con­duc­tor et abon­né à la liste bioc-devel

Vous pen­sez avoir res­pec­té ces recom­man­da­tions ain­si que la liste com­plète sur leur site ? Pas­sons à la véri­fi­ca­tion ! Tout d'abord, ins­tal­lez le package Bioc­Check car les checks de Bio­con­duc­tor ne se trouvent pas nati­ve­ment dans l'install de R. Ensuite, lan­cez-le depuis votre ses­sion R en vous assu­rant d'avoir votre wor­king

BiocManager::install("BiocCheck")

BiocCheck::BiocCheck()

Des erreurs/​warnings vont à nou­veau s'afficher, et recom­mence le jeu de la cor­rec­tion en fonc­tion des mes­sages don­nés.

À savoir que même si les NOTEs sont en théo­rie accep­tées, il suf­fit que vous tom­biez sur un revie­wer un peu zélé pour que vous deviez éga­le­ment les cor­ri­ger entiè­re­ment. Voi­ci un exemple de rap­port Bioc­Check :

Sum­ma­ry :
ERROR count : 0
WARNING count : 0
NOTE count : 7
For detai­led infor­ma­tion about these checks, see the Bioc­Check vignette, avai­lable at
https://​bio​con​duc​tor​.org/​p​a​c​k​a​g​e​s​/​3​.​1​1​/​b​i​o​c​/​v​i​g​n​e​t​t​e​s​/​B​i​o​c​C​h​e​c​k​/​i​n​s​t​/​d​o​c​/​B​i​o​c​C​h​e​c​k​.​h​t​m​l​#​i​n​t​e​r​p​r​e​t​i​n​g​-​b​i​o​c​c​h​e​c​k​-​o​u​t​put
$error
character(0)

$war­ning
character(0)

$note
[1] "Consi­der cla­ri­fying how 4 object(s) are ini­tia­li­zed. Maybe they are part of a data set loa­ded with data(), or per­haps part of an object refe­ren­ced in with() or within()."
[2] " Avoid sap­ply(); use vap­ply()"
[3] " Avoid 1:…; use seq_​len() or seq_​along()"
[4] "Recom­men­ded func­tion length <= 50 lines."
[5] "Consi­der adding run­nable examples to the fol­lo­wing man pages which docu­ment expor­ted objects:"
[6] "Consi­der adding a NEWS file, so your package news will be inclu­ded in Bio­con­duc­tor release announ­ce­ments."
[7] "Can­not deter­mine whe­ther main­tai­ner is sub­scri­bed to the bioc-devel mai­ling list (requires adminn­cre­den­tials). Sub­scribe here : https://​stat​.ethz​.ch/​m​a​i​l​m​a​n​/​l​i​s​t​i​n​f​o​/​b​i​o​c​-​d​e​vel"

Comme vous le voyez il reste des NOTEs, libre à vous de choi­sir de les cor­ri­ger à pré­sent ou attendre de voir si le revie­wer vous l'impose (per­son­nel­le­ment j'ai per­du à ce jeu comme vous pour­rez le voir dans la sec­tion Retour d'expérience per­son­nelle).

Le processus de soumission à Bioconductor

Tout semble bon ? Ça com­pile ? Vous pas­sez tous les checks ? Bien, pas­sons à la sou­mis­sion de votre package.

• Si ce n'est pas déjà fait, pous­sez votre package sur GitHub (et si vous n'y connais­sez rien à git, lisez cet article 😉 ). C'est en effet l'hebergeur qu'a choi­si Bio­con­duc­tor pour gérer la sou­mis­sion et le sui­vi du déve­lop­pe­ment des packages (mais rien ne vous empêche d'avoir votre repo sur un Git­Lab, Bit­bu­cket, etc. à côté bien évi­dem­ment).
• Créez une issue sur le repo Contri­bu­tions de Bio­con­duc­tor en sui­vant le guide four­nit. Rajou­tez un petit bon­jour et une phrase rapide de des­crip­tion, ça ne mange pas de pain non plus.
• Créez un web­hook pour votre repo. Cela va per­mettre au bot qui gère l'automatisation des sou­mis­sions d'être infor­mé qu'il y a un nou­veau package à aller cher­cher, et par la suite ça per­met­tra qu'il soit infor­mé quand vous effec­tuez des modi­fi­ca­tions sur votre repo (cor­rec­tion de code, ajout de nou­velle fonc­tion­na­li­té…).
• Ajou­tez une clef SSH publique. Elle sera uti­li­sée pour copier votre repo une fois votre package accep­té.
• Atten­dez… Votre package va être tagué comme "1. awai­ting mode­ra­tion'" en atten­dant, comme c'est dit dans le tag, qu'un revie­wer soit assi­gné et vienne esti­mer si votre package vaut le coup d'être ajou­té à Bio­con­duc­tor.
• Si sa per­ti­nance est jugée bonne, le tag chan­ge­ra pour "2. review in pro­gress" et le bot com­men­ce­ra alors à re-exé­cu­ter tous les checks que vous avez en théo­rie déjà pas­sés haut la main.
• Et là… Peu importe si vous avez mis tout votre cœur, sueur et temps dans vos checks, peu importe que ça roule sur votre PC et votre VM pour l'autre OS, vous allez avoir des erreurs ! Mur­phy, si tu nous entends…
• Le bot va taguer votre issue avec ERROR ou WARNINGS ain­si que vous don­ner un lien vers un rap­port détaillé des tests et erreurs obte­nues pour cha­cun des OS (voir Figure 4, atten­tion, ça pique les yeux). Et si Mur­phy vous a épar­gné, sau­tez direc­te­ment trois points plus loin (ne pas­sez pas par la case départ, ne tou­chez pas 20K).
• Com­mence alors un nou­veau cycle d'essai/erreur pour la cor­rec­tion des der­niers sou­cis qui sont appa­rus. Cepen­dant, pour que le bot prenne en compte les modi­fi­ca­tions, il vous fau­dra incré­men­ter la ver­sion de votre package. Vous com­men­cez nor­ma­le­ment à 0.99.0 (for­mat impo­sé par Bio­con­duc­tor) et à chaque modi­fi­ca­tion que vous pous­sez et où vous sou­hai­te­rez une éva­lua­tion, il fau­dra pas­ser à 0.99.1, 0.99.2, etc.
• Notez que si le bot détecte des modi­fi­ca­tions pous­sées mais pas d'incrément, il tague­ra votre issue avec "VERSION BUMP REQUIRED". Il est donc de bonne pra­tique d'effectuer vos modi­fi­ca­tions sur une autre branche que le mas­ter, puis de mer­ger avec le mas­ter quand vous avez fini votre modi­fi­ca­tion et fait repas­ser tous les tests. Je ne sau­rais que trop vous recom­man­der un modèle de branches git de ce type. Atten­tion, n'incrémentez la ver­sion qu'après le merge, sinon le bot ne déclenche pas un nou­veau build.

• Une fois toutes les modi­fi­ca­tions faites pour n'avoir aucunes erreurs et le pré­cieux tag "OK", votre revie­wer va éva­luer votre package. C'est notam­ment à ce moment-là que vous ver­rez s'il vous demande d'adresser les NOTEs lais­sées, si vous ne sui­vez pas des gui­de­lines non tes­tées auto­ma­ti­que­ment comme l'utilisation des com­mon classes. Il vous deman­de­ra pro­ba­ble­ment des modi­fi­ca­tions, et vous repar­ti­rez pour un nou­veau cycle d'essai/erreur.
• Enfin, une fois tout cela fini, l'encore plus pré­cieux tag "3a. accep­ted" vous sera nor­ma­le­ment attri­bué et votre package sera ajou­té au repo de Bio­con­duc­tor. Il sera alors publié avec la pro­chaine release à venir.
• Si pour une rai­son ou une autre votre package était tagué "3b. decli­ned", n'hésitez pas à com­mu­ni­quer avec les revie­wers pour en connaitre la rai­son.

Vous pou­vez souf­fler, c'est fait ! À pré­sent, il ne vous reste plus qu'à savou­rer votre vic­toire, et vous assu­rer à chaque release de Bio­con­duc­tor (2 fois par an donc) que votre package com­pile tou­jours et passe les checks.

Retour d'expérience personnelle et astuces

Avant de vous lais­ser avec quelques conclu­sions, je vou­drais vous appor­ter rapi­de­ment quelques points basés sur un res­sen­ti per­son­nel de cette "expé­rience" :

• Le pro­ces­sus est LONG, et c'est un euphé­misme. Entre les checks de base qui ne passent pas, puis ceux de Bioc­Checks, il y a déja pas mal de temps pas­sé à cor­ri­ger le code, et je les pas­sais pour­tant régu­liè­re­ment au cours de mon déve­lop­pe­ment ain­si que mes tests uni­taires + la même chose sur ma VM Win­dows. Quand une fois fini j'ai vu de nou­velles erreurs s'afficher dans le rap­port du bot de Bio­con­duc­tor, j'ai ragé assez fort… Je main­tiens que la fonc­tion Bioc­Check devrait inté­grer ces tests sup­plé­men­taires effec­tués sur leurs ser­veurs…
• Si vous visez une release en par­ti­cu­lier, pre­nez-vous‑y à l'avance de faci­le­ment 1 à 2 mois. Les revie­wers sont sur­char­gés sur la fin et mettent du temps à faire les reviews. Le mien n'a d'ailleurs don­né de signe de vie que deux semaines après la date but­toir de dépôt, me lais­sant moins de 5 jours pour cor­ri­ger les nom­breuses remarques qu'il m'a faites. J'ai fina­le­ment lou­pé la release…
• J'ai aus­si eu la mal­chance de tom­ber en plein chan­ge­ment de ver­sion majeure de R (3.6 -> 4.0) sur laquelle vous devez tes­ter votre package, alors que la release offi­cielle n'est pas encore dis­po­nible. À vous les joies de la com­pi­la­tion de la R‑alpha ! Ou sinon vous faites les bour­rins et vous vous ser­vez du rap­port d'erreur du bot Bio­con­duc­tor mais c'est pas mal plus lent de faire les allers-retours, et je pré­fère avec un mas­ter (un peu) propre.
• Met­tez vos packages à jour avant de pous­ser sur Bio­con­duc­tor, vrai­ment. Ça évite de ron­chon­ner sur votre revie­wer en disant que vous n'arrivez pas à repro­duire ce bug magique qui n'existe que sur leurs ser­veurs et sur aucune de vos VM (et donc évi­ter de pas­ser pour une andouille).
• Pour ceux qui déve­loppent sous Linux et ne veulent pas se prendre la tête avec une VM, il existe win-buil­der. Vous pou­vez d'ailleurs l'utiliser direc­te­ment dans dev­tools avec la fonc­tion check_​win_​release(). Je ne l'ai décou­vert qu'après avoir mon­té ma VM et com­pi­lé la R‑alpha des­sus…
• À la relec­ture, Guillaume m'a par­lé de R‑hub. C'est une ver­sion plus pous­sée de win-buil­der qui vous per­met de faire les checks sur sur une grande varié­té d'OS et de ver­sions de cha­cun. Très utile aus­si donc 😉
• Cer­tains revie­wers sont mieux que d'autres : le mien était par­ti­cu­liè­re­ment désa­gréable dans sa façon de par­ler et assez zélé. Il m'a obli­gé à cor­ri­ger l'intégralité des NOTEs. Mais d'autres sont char­mants et com­prennent que cer­taines NOTEs ne jus­ti­fient pas un refus du package.

Conclusion

La sou­mis­sion d'un package de Bio­con­duc­tor est une épreuve en soi. Il y a de quoi se décou­ra­ger à de maintes reprises, mais le résul­tat est là : un package visible par toute la com­mu­nau­té bioin­fo. Il sera donc plus faci­le­ment par­ta­geable et pour­ra poten­tiel­le­ment deve­nir incon­tour­nable dans votre domaine.

Bon cou­rage à vous si vous vous lan­cez dedans !

Mer­ci à mes relec­teurs Guillaume, lhtd, et neo­lem pour la relec­ture de cet article assez dense !

Références

• Le site de bio­con­duc­tor
• Une ana­lyse des sou­mis­sions sur Bio­con­duc­tor très détaillée : taux de rejet/​acceptation, temps de réponse des revie­wers, per­io­di­ci­té des sou­mis­sions, etc.
• Les superbes tuto­riels (en fran­çais) de mes col­lègues Charles Joly-Beau­par­lant et Éric Four­nier. Ils sont écrits de façon décon­trac­tée avec un conden­sé du mini­mum à savoir, des outils pour vous faire gagner du temps, et de quelques bonnes pra­tiques. L'un porte sur la créa­tion d'un package R, l'autre sur le pro­ces­sus de sou­mis­sion à Bio­con­duc­tor, et un der­nier que je n'ai pas encore appli­qué qui porte sur l'inté­gra­tion conti­nue via Tra­vis.
• L'incontournable livre d'Hadley Wick­ham sur le déve­lop­pe­ment package R
• L'article de blog What I've learnt about making an R package qui donne des petites sub­ti­li­tés sur le déve­lop­pe­ment de packages R et notam­ment sur la docu­men­ta­tion