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.

Figure 1 : évo­lu­tion du nombre de packages dépo­sés sur Bio­con­duc­tor

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 :

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.
Figure 2 : Inter­face de Rstu­dio avec la loca­li­sa­tion de la fenêtre de build et le bou­ton de com­pi­la­tion du package source.

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

✓  checking for file ‘/home/bioinfofr/dev/R/mypkg/DESCRIPTION’ ...
─  preparing ‘mypkg’: (1s)
✓  checking DESCRIPTION meta-information ...
─  installing the package to build vignettes
✓  creating vignettes (2m 8s)
─  checking for LF line-endings in source and make files and shell scripts
─  checking for empty or unneeded directories
   Removed empty directory ‘mypkg/tests’
─  building ‘mypkg_0.99.99.tar.gz’
   
[1] "/home/bioinfofr/dev/R/mypkg_0.99.99.tar.gz"

Source package written to ~/dev/R


Et sinon... Eh bien les messages d'erreurs sont plutôt explicites sur la source du problème. Le plus souvent vous aurez simplement mal respecté l'architecture d'un package R (un dossier mal nommé, des fichiers qui traînent, etc.) ou des informations manquantes dans le fichier DESCRIPTION.

Une fois que votre package est compilé, passons aux checks (vérifications) automatiques. À nouveau, deux choix s'offrent à vous :

  • En shell : Il vous faudra faire rouler la commande R CMD check. Exemple : R CMD check /home/bioinfofr/dev/R/mypkg
  • Avec Rstudio/devtools : rendez-vous dans l'onglet build comme en Figure 3 et cliquez sur Check. Cela lance la fonction devtools::check().
Figure 3 : Interface de Rstudio avec la localisation de la fenêtre de build et le bouton de check

Une fois terminé, voici le genre de rapport que vous devriez obtenir :

── Building ──────────────────────────────────── mypkg ──
Setting env vars:
● CFLAGS    : -Wall -pedantic -fdiagnostics-color=always
● CXXFLAGS  : -Wall -pedantic -fdiagnostics-color=always
● CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always
─────────────────────────────────────────────────────────
✓  checking for file ‘/home/bioinfofr/dev/R/mypkg/DESCRIPTION’ (372ms)
─  preparing ‘mypkg’: (1.5s)
✓  checking DESCRIPTION meta-information ...
─  installing the package to build vignettes
✓  creating vignettes (2m 17.3s)
─  checking for LF line-endings in source and make files and shell scripts (351ms)
─  checking for empty or unneeded directories
   Removed empty directory ‘mypkg/tests’
─  building ‘mypkg_0.99.99.tar.gz’
   
── Checking ──────────────────────────────────── mypkg ──
Setting 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 directory ‘/home/bioinfofr/dev/R/mypkg/mypkg.Rcheck’ (517ms)
─  using R version 4.0.0 (2020-04-24)
─  using platform: x86_64-pc-linux-gnu (64-bit)
─  using session charset: UTF-8
─  using options ‘--no-manual --as-cran’ (692ms)
✓  checking for file ‘mypkg/DESCRIPTION’
─  this is package ‘mypkg’ version ‘0.99.99’
─  package encoding: UTF-8
✓  checking package namespace information ...
✓  checking package dependencies (6.5s)
✓  checking if this is a source package
✓  checking if there is a namespace
✓  checking for executable files (510ms)
✓  checking for hidden files and directories
✓  checking for portable file names ...
✓  checking for sufficient/correct file permissions
✓  checking whether package ‘mypkg’ can be installed (24.9s)
N  checking installed package size ...
     installed size is 10.2Mb
     sub-directories of 1Mb or more:
       data   5.6Mb
       doc    4.1Mb
✓  checking package directory ...
✓  checking for future file timestamps (1.1s)
✓  checking ‘build’ directory
✓  checking DESCRIPTION meta-information ...
✓  checking top-level files
✓  checking for left-over files
✓  checking index information ...
✓  checking package subdirectories ...
✓  checking R files for non-ASCII characters ...
✓  checking R files for syntax errors ...
✓  checking whether the package can be loaded (8s)
✓  checking whether the package can be loaded with stated dependencies (7.9s)
✓  checking whether the package can be unloaded cleanly (7.3s)
✓  checking whether the namespace can be loaded with stated dependencies (7.4s)
✓  checking whether the namespace can be unloaded cleanly (7.6s)
✓  checking loading without being on the library search path (7.6s)
✓  checking dependencies in R code (7.1s)
✓  checking S3 generic/method consistency (10.2s)
✓  checking replacement functions (7.2s)
✓  checking foreign function calls (7.4s)
✓  checking R code for possible problems (26s)
✓  checking Rd files (339ms)
✓  checking Rd metadata ...
✓  checking Rd line widths ...
✓  checking Rd cross-references ...
✓  checking for missing documentation entries (7.9s)
✓  checking for code/documentation mismatches (23.6s)
✓  checking Rd usage sections (9.6s)
✓  checking Rd contents ...
✓  checking for unstated dependencies in examples ...
✓  checking contents of ‘data’ directory (380ms)
✓  checking data for non-ASCII characters (657ms)
✓  checking data for ASCII and uncompressed saves ...
✓  checking installed files from ‘inst/doc’ ...
✓  checking files in ‘vignettes’ ...
✓  checking examples (1m 21.8s)
   Examples with CPU (user + system) or elapsed time > 5s
                        user system elapsed
   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
✓  checking for unstated dependencies in vignettes ...
✓  checking package vignettes in ‘inst/doc’ ...
✓  checking re-building of vignette outputs (1m 47.3s)
✓  checking for non-standard things in the check directory
✓  checking for detritus in the temp directory
   
   See
     ‘/home/bioinfofr/dev/R/mypkg/mypkg.Rcheck/00check.log’
   for details.
   
   
── R CMD check results ────────────────────────────────────── mypkg 0.99.99 ────
Duration: 6m 14.2s

> checking installed package size ... NOTE
    installed size is 10.2Mb
    sub-directories of 1Mb or more:
      data   5.6Mb
      doc    4.1Mb

0 errors ✓ | 0 warnings ✓ | 1 notes x

R CMD check succeeded


Comme vous le voyez, le risque d'erreurs/avertissements est assez grand (trop grand pour que je couvre ici tous les cas !). Mais rassurez-vous, personne ne pense à tout dès la première fois qu'il développe son package. Vous finirez donc irrémédiablement avec des corrections à faire, car pour pouvoir soumettre votre package, vous ne devez avoir aucune ERROR ou WARNING. La meilleure pratique pour éviter d'avoir des dizaines de corrections à faire, c'est de tester le build et exécuter les checks régulièrement dans votre processus de développement (ça vous évitera de devoir recoder des pans entiers de votre outil car l'erreur vient d'un bout de code sur lequel s'appuient d'autres). Pensez également à mettre à jour les packages sur votre poste local car ce sont les dernières version de ceux-ci qui seront utilisées par le CRAN pour rouler les checks de leur côté (et pareil pour Bioconductor).

Les NOTEs sont quant à elles tolérées dans une certaine mesure, et cette mesure est à la discrétion de la personne qui fera la relecture critique de votre package (mais comme nous allons viser Bioconductor dans cet article, ce sont d'autres reviewers 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 falloir passer ceux de Bioconductor ! Et c'est pas gagné.

Bioconductor est encore plus restrictif que le CRAN sur ses tests appelés BiocCheck. En effet, ils ont défini tout un ensemble de bonnes pratiques supplémentaires liées à la fois aux spécificités bioinformatiques, à la lisibilité du code, à des recommandations sur l'utilisation de telle ou telle façon de coder. Si certains de leurs partis pris sont discutables, il n'en reste pas moins que vous allez devoir vous y soumettre.

À défaut de vous les lister tous, je vais vous indiquer le minimum à respecter pour vous éviter masse de changement. L'idéal reste tout de même de les lire avant de commencer à développer votre package, car certains vont fortement impacter votre package.

  • Il va falloir définir à quelle catégorie votre package appartient : Software, Experiment Data, ou Annotation. La première est celle regroupant les outils d'analyse à proprement dit. Les deux dernières sont des packages de données aux noms assez explicites quant à leur contenu.
  • Si votre package utilise des données classiques en bioinfo (matrices gènes X échantillons, FASTA, VCF, spectro de masse, etc.) sachez que vous devrez au moins rendre compatible votre package avec les common classes de Bioconductor. Ces formats sont une tentative de standardisation de l'input dans les packages de ce dépôt.
  • Si c'est un Software, votre package final devra faire moins de 5Mo. Attention donc aux jeux de données d'exemple que vous insérez dedans. Si jamais vous souhaitez inclure des données plus grosses, on vous conseille de soumettre un autre package de type Experiment Data, ou Annotation et de l'appeler dans votre package.
  • Il devra être compatible Linux ET Windows ! Mauvaise idée donc de se baser sur des spécificités de votre OS. Ou alors préparez-vous à devoir développer un équivalent dans l'autre OS.
  • Toutes vos fonctions/données doivent être documentées ! Et pas seulement avec une rapide description. On parle d'une explication des paramètres, d'une valeur retour, et surtout d'un exemple exécutable fonctionnel.
  • Il faudra écrire une vignette, ce document faisant office d'introduction à votre package et de tutoriel. Il est nécessaire qu'on passe à travers un maximum des fonctionnalités de votre package, l'idéal étant d'y réaliser une analyse type, sur de véritables données ou des données simulées.
  • Les tests unitaires ne sont pas obligatoires d'après leur guidelines, mais soyez assurés qu'ils vous les demanderont tout de même pour la majorité de vos fonctions au moment de la revue. Mais en tant que bioinformaticien consciencieux vous les auriez déjà faits n'est-ce pas ;) ?
  • Vous devez être inscrits au site de support de Bioconductor et abonné à la liste bioc-devel

Vous pensez avoir respecté ces recommandations ainsi que la liste complète sur leur site ? Passons à la vérification ! Tout d'abord, installez le package BiocCheck car les checks de Bioconductor ne se trouvent pas nativement dans l'install de R. Ensuite, lancez-le depuis votre session R en vous assurant d'avoir votre working

if (!requireNamespace("BiocManager", quietly = TRUE))
    install.packages("BiocManager")

BiocManager::install("BiocCheck")

BiocCheck::BiocCheck()


Des erreurs/warnings vont à nouveau s'afficher, et recommence le jeu de la correction en fonction des messages donnés.

À savoir que même si les NOTEs sont en théorie acceptées, il suffit que vous tombiez sur un reviewer un peu zélé pour que vous deviez également les corriger entièrement. Voici un exemple de rapport BiocCheck :

This is BiocCheck version 1.24.0. BiocCheck is a work in progress. Output and severity of issues
may change. Installing package...
* Checking Package Dependencies...
* Checking if other packages can import this one...
* Checking to see if we understand object initialization...
* NOTE: Consider clarifying how 4 object(s) are initialized. Maybe they are part of a dataset loaded with data(), or perhaps part of an object referenced in with() or within().
function (object)
my_foo_one (.)
my_foo_two (sides)
my_foo_de_vous (ouuuh)
my_foo_foo_ne (.)
* Checking for deprecated package usage...
* Checking for remote package usage...
* Checking version number...
* Checking version number validity...
Package version 0.99.99; pre-release
* Checking R Version dependency...
* Checking package size...
Skipped... only checked on source tarball
* Checking individual file sizes...
* Checking biocViews...
* Checking that biocViews are present...
* Checking package type based on biocViews...
Software
* Checking for non-trivial biocViews...
* Checking that biocViews come from the same category...
* Checking biocViews validity...
* Checking for recommended biocViews...
* Checking build system compatibility...
* Checking for blank lines in DESCRIPTION...
* Checking if DESCRIPTION is well formatted...
* Checking for whitespace in DESCRIPTION field names...
* Checking that Package field matches directory/tarball name...
* Checking for Version field...
* Checking for valid maintainer...
* Checking DESCRIPTION/NAMESPACE consistency...
* Checking vignette directory...
This is a software package
* Checking library calls...
* Checking for library/require of mypkg...
* Checking coding practice...
* NOTE: Avoid sapply(); use vapply()
Found in files:
foo_fighters.R (line 145, column 17)
* NOTE: Avoid 1:...; use seq_len() or seq_along()
Found in files:
foo_tre.R (line 83, column 67)
* Checking parsed R code in R directory, examples, vignettes...
* Checking function lengths..................................
* NOTE: Recommended function length <= 50 lines.
There are 2 functions > 50 lines.
foo_taj_2_gueule() (R/foo_rage.R, line 59): 194 lines
foo_l() (R/foo_fly.R, line 301): 113 lines
* Checking man page documentation...
* NOTE: Consider adding runnable examples to the following man pages which document exported
objects:
foo_lure.Rd
* Checking package NEWS...
* NOTE: Consider adding a NEWS file, so your package news will be included in Bioconductor
release announcements.
* Checking unit tests...
* Checking skip_on_bioc() in tests...
* Checking formatting of DESCRIPTION, NAMESPACE, man pages, R source, and vignette source...
* Checking if package already exists in CRAN...
* Checking for bioc-devel mailing list subscription...
* NOTE: Cannot determine whether maintainer is subscribed to the bioc-devel mailing list (requires admin credentials).  Subscribe here:
https://stat.ethz.ch/mailman/listinfo/bioc-devel
* Checking for support site registration...
Maintainer is registered at support site.


Summary:
ERROR count: 0
WARNING count: 0
NOTE count: 7
For detailed information about these checks, see the BiocCheck vignette, available at
https://bioconductor.org/packages/3.11/bioc/vignettes/BiocCheck/inst/doc/BiocCheck.html#interpreting-bioccheck-output
$error
character(0)

$warning
character(0)

$note
[1] "Consider clarifying how 4 object(s) are initialized. Maybe they are part of a data set loaded with data(), or perhaps part of an object referenced in with() or within()."       
[2] " Avoid sapply(); use vapply()"                                                                                                                                                    
[3] " Avoid 1:...; use seq_len() or seq_along()"                                                                                                                                       
[4] "Recommended function length <= 50 lines."                                                                                                                                         
[5] "Consider adding runnable examples to the following man pages which document exported objects:"                                                                                    
[6] "Consider adding a NEWS file, so your package news will be included in Bioconductor release announcements."                                                                                                                                                                          
[7] "Cannot determine whether maintainer is subscribed to the bioc-devel mailing list (requires adminncredentials).  Subscribe here: https://stat.ethz.ch/mailman/listinfo/bioc-devel"


Comme vous le voyez il reste des NOTEs, libre à vous de choisir de les corriger à présent ou attendre de voir si le reviewer vous l'impose (personnellement j'ai perdu à ce jeu comme vous pourrez le voir dans la section Retour d'expérience personnelle).

Le processus de soumission à Bioconductor

Tout semble bon ? Ça compile ? Vous passez tous les checks ? Bien, passons à la soumission de votre package.

  • Si ce n'est pas déjà fait, poussez votre package sur GitHub (et si vous n'y connaissez rien à git, lisez cet article ;) ). C'est en effet l'hebergeur qu'a choisi Bioconductor pour gérer la soumission et le suivi du développement des packages (mais rien ne vous empêche d'avoir votre repo sur un GitLab, Bitbucket, etc. à côté bien évidemment).
  • Créez une issue sur le repo Contributions de Bioconductor en suivant le guide fournit. Rajoutez un petit bonjour et une phrase rapide de description, ça ne mange pas de pain non plus.
  • Créez un webhook pour votre repo. Cela va permettre au bot qui gère l'automatisation des soumissions d'être informé qu'il y a un nouveau package à aller chercher, et par la suite ça permettra qu'il soit informé quand vous effectuez des modifications sur votre repo (correction de code, ajout de nouvelle fonctionnalité...).
  • Ajoutez une clef SSH publique. Elle sera utilisée pour copier votre repo une fois votre package accepté.
  • Attendez... Votre package va être tagué comme "1. awaiting moderation'" en attendant, comme c'est dit dans le tag, qu'un reviewer soit assigné et vienne estimer si votre package vaut le coup d'être ajouté à Bioconductor.
  • Si sa pertinance est jugée bonne, le tag changera pour "2. review in progress" et le bot commencera alors à re-exécuter tous les checks que vous avez en théorie déjà passé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 ! Murphy, si tu nous entends…
  • Le bot va taguer votre issue avec ERROR ou WARNINGS ainsi que vous donner un lien vers un rapport détaillé des tests et erreurs obtenues pour chacun des OS (voir Figure 4, attention, ça pique les yeux). Et si Murphy vous a épargné, sautez directement trois points plus loin (ne passez pas par la case départ, ne touchez pas 20K).
  • Commence alors un nouveau cycle d'essai/erreur pour la correction des derniers soucis qui sont apparus. Cependant, pour que le bot prenne en compte les modifications, il vous faudra incrémenter la version de votre package. Vous commencez normalement à 0.99.0 (format imposé par Bioconductor) et à chaque modification que vous poussez et où vous souhaiterez une évaluation, il faudra passer à 0.99.1, 0.99.2, etc.
  • Notez que si le bot détecte des modifications poussées mais pas d'incrément, il taguera votre issue avec "VERSION BUMP REQUIRED". Il est donc de bonne pratique d'effectuer vos modifications sur une autre branche que le master, puis de merger avec le master quand vous avez fini votre modification et fait repasser tous les tests. Je ne saurais que trop vous recommander un modèle de branches git de ce type. Attention, n'incrémentez la version qu'après le merge, sinon le bot ne déclenche pas un nouveau build.
Figure 4 : Exemple d'un rapport de build que vous donne le bot Bioconductor en lien dans votre issue sur GitHub
  • Une fois toutes les modifications faites pour n'avoir aucunes erreurs et le précieux tag "OK", votre reviewer va évaluer votre package. C'est notamment à ce moment-là que vous verrez s'il vous demande d'adresser les NOTEs laissées, si vous ne suivez pas des guidelines non testées automatiquement comme l'utilisation des common classes. Il vous demandera probablement des modifications, et vous repartirez pour un nouveau cycle d'essai/erreur.
  • Enfin, une fois tout cela fini, l'encore plus précieux tag "3a. accepted" vous sera normalement attribué et votre package sera ajouté au repo de Bioconductor. Il sera alors publié avec la prochaine release à venir.
  • Si pour une raison ou une autre votre package était tagué "3b. declined", n'hésitez pas à communiquer avec les reviewers pour en connaitre la raison.

Vous pouvez souffler, c'est fait ! À présent, il ne vous reste plus qu'à savourer votre victoire, et vous assurer à chaque release de Bioconductor (2 fois par an donc) que votre package compile toujours et passe les checks.

Retour d'expérience personnelle et astuces

Avant de vous laisser avec quelques conclusions, je voudrais vous apporter rapidement quelques points basés sur un ressenti personnel de cette "expérience" :

  • Le processus est LONG, et c'est un euphémisme. Entre les checks de base qui ne passent pas, puis ceux de BiocChecks, il y a déja pas mal de temps passé à corriger le code, et je les passais pourtant régulièrement au cours de mon développement ainsi que mes tests unitaires + la même chose sur ma VM Windows. Quand une fois fini j'ai vu de nouvelles erreurs s'afficher dans le rapport du bot de Bioconductor, j'ai ragé assez fort... Je maintiens que la fonction BiocCheck devrait intégrer ces tests supplémentaires effectués sur leurs serveurs...
  • Si vous visez une release en particulier, prenez-vous-y à l'avance de facilement 1 à 2 mois. Les reviewers sont surchargés sur la fin et mettent du temps à faire les reviews. Le mien n'a d'ailleurs donné de signe de vie que deux semaines après la date buttoir de dépôt, me laissant moins de 5 jours pour corriger les nombreuses remarques qu'il m'a faites. J'ai finalement loupé la release…
  • J'ai aussi eu la malchance de tomber en plein changement de version majeure de R (3.6 -> 4.0) sur laquelle vous devez tester votre package, alors que la release officielle n'est pas encore disponible. À vous les joies de la compilation de la R-alpha ! Ou sinon vous faites les bourrins et vous vous servez du rapport d'erreur du bot Bioconductor mais c'est pas mal plus lent de faire les allers-retours, et je préfère avec un master (un peu) propre.
  • Mettez vos packages à jour avant de pousser sur Bioconductor, vraiment. Ça évite de ronchonner sur votre reviewer en disant que vous n'arrivez pas à reproduire ce bug magique qui n'existe que sur leurs serveurs et sur aucune de vos VM (et donc éviter de passer pour une andouille).
  • Pour ceux qui développent sous Linux et ne veulent pas se prendre la tête avec une VM, il existe win-builder. Vous pouvez d'ailleurs l'utiliser directement dans devtools avec la fonction check_win_release(). Je ne l'ai découvert qu'après avoir monté ma VM et compilé la R-alpha dessus...
  • À la relecture, Guillaume m'a parlé de R-hub. C'est une version plus poussée de win-builder qui vous permet de faire les checks sur sur une grande variété d'OS et de versions de chacun. Très utile aussi donc ;)
  • Certains reviewers sont mieux que d'autres : le mien était particulièrement désagréable dans sa façon de parler et assez zélé. Il m'a obligé à corriger l'intégralité des NOTEs. Mais d'autres sont charmants et comprennent que certaines NOTEs ne justifient pas un refus du package.

Conclusion

La soumission d'un package de Bioconductor est une épreuve en soi. Il y a de quoi se décourager à de maintes reprises, mais le résultat est là : un package visible par toute la communauté bioinfo. Il sera donc plus facilement partageable et pourra potentiellement devenir incontournable dans votre domaine.

Bon courage à vous si vous vous lancez dedans !

Merci à mes relecteurs Guillaume, lhtd, et neolem pour la relecture de cet article assez dense !

Références



Pour continuer la lecture :


Commentaires

3 réponses à “Pourquoi et comment déposer un package R sur Bioconductor ?”

  1. Avatar de Yoann M.
    Yoann M.

    Super article Gwen ! Ça sent le vécu et le retour d'expérience qui sera sur­ement très utile à d'autres. J'ai hâte de décou­vrir ton package quand tu pour­ras enfin com­mu­ni­quer des­sus. Bon cou­rage !

    1. Dès que pos­sible 😉

  2. Avatar de Jonathan Kitt
    Jonathan Kitt

    Mer­ci pour cet article très inté­res­sant ! Je suis en plein dans les cor­rec­tions diverses pour réduire le nombre de errors/​warnings/​notes … effec­ti­ve­ment c'est long 🙂

Laisser un commentaire