Comment debugger votre package dans un conteneur fedora {rhub} avant d'envoyer sur le CRAN ?

Pourquoi un autre billet de blog sur le débogage ?

Dans un article précédent, j’ai présenté “Déboguer son package qui a échoué sur CRAN grâce à {rhub}”. Ici, c’est exactement le même article de blog, parce que vous savez, je ne lis pas mes propres articles, et je rencontre et corrige les mêmes erreurs encore et encore…
Mais je ne suis pas aussi stupide qu’il n’y paraît. Cette fois, je n’ai pas pu reproduire les mêmes étapes car aujourd’hui, le rhub::local_check_linux() n’a pas fonctionné comme prévu. Peut-être que mon installation locale de docker est différente ou que quelque chose a changé dans les images… Je n’en sais rien.

Si vous voulez explorer localement ce qui se passe à l’intérieur d’un conteneur {rhub}, je vous suggère d’essayer le premier article de blog, et si ça ne marche pas, alors suivez celui-ci.

Notez que dans le présent article, je montre des astuces pour sauvegarder l’image docker actuelle, et j’ai aussi utilisé VSCode pour entrer dans le conteneur.

Dans la série débogage, il y a aussi “Comment déboguer son package sur Win-Builder avant d’envoyer vers le CRAN ?”, qui est différent parce que vous utilisez le winbuilder distant pour vous aider dans le processus, et il n’y a pas de possibilité de session interactive.

Check your on {rhub} pour explorer les résultats sur plusieurs plateformes

Avant d’envoyer votre paquet au CRAN, vous l’avez probablement vérifié sur {rhub}.
Avec des packages compliqués, j’aime tester sur plusieurs plateformes pour réduire les risques d’être rejeté par le CRAN après les premières étapes de la soumission. En effet, des plateformes spécifiques comme ‘fedora’ sont testées uniquement après l’acceptation de votre paquet sur le CRAN. Si votre paquet échoue sur ces plateformes après l’acceptation, vous n’aurez que 2 semaines pour le corriger.

Pour tester sur plusieurs images sans avoir à compiler votre package à chaque fois, j’ai l’habitude de le compiler une fois et d’utiliser l’argument path dans les fonctions rhub::check...() comme ci-dessous :

buildpath <- devtools::build()
rhub::platforms()
rhub::check_on_windows(check_args = "--force-multiarch", show_status = FALSE, path = buildpath)
rhub::check_on_solaris(show_status = FALSE, path = buildpath)
rhub::check(platform = "debian-clang-devel", show_status = FALSE, path = buildpath)
rhub::check(platform = "debian-gcc-devel", show_status = FALSE, path = buildpath)
rhub::check(platform = "fedora-clang-devel", show_status = FALSE, path = buildpath)
rhub::check_for_cran(show_status = FALSE, path = buildpath)

Vérifier localement sur ces mêmes plateformes

Avec la fonction local_check_linux(), {rhub} vous permet d’exécuter un conteneur docker localement sur votre machine pour réaliser les mêmes tests que ceux envoyés aux serveurs ‘rhub’.
L’utilisation de docker fonctionne bien sur les distributions Ubuntu comme celle que j’utilise actuellement.

rhub::local_check_linux(image = "rhub/fedora-clang-devel")

Explorer et tester depuis l’intérieur du conteneur

La fonction local_check_linux() ne permet pas directement d’exécuter depuis l’intérieur. En effet, vous allez devoir utiliser l’image de ‘rhub’ et la lancer en mode interactif, trouver R, et installer vos dépendances.

Pour ce faire, ouvrez un Terminal sur votre machine et exécutez les lignes de commandes suivantes. Ici, j’utilise “/home/seb/checkhelper” comme le package que je souhaite vérifier dans le conteneur. Je dois monter ce répertoire dans le conteneur en utilisant l’argument -v.

# download rhub container
docker pull rhub/debian-clang-devel

# run container and mount your project inside
docker run -v /home/seb/checkhelper:/home/root/checkhelper -it rhub/fedora-clang-devel:latest bash

# Once inside, find and run R from "/opt"
/opt/R-devel/bin/R

Vous utilisez maintenant R dans le conteneur. Installez toutes les dépendances, y compris “Suggests” si vous voulez pouvoir tester votre paquet.

setwd("/home/root/checkhelper")
install.packages("remotes")
remotes::install_deps(dependencies = TRUE)

# Install also devtools
remotes::install_cran("devtools")

Certains packages peuvent nécessiter des dépendances supplémentaires. Lisez attentivement les erreurs d’installation pour trouver les bibliothèques à installer.
Par exemple, j’avais besoin de ‘openssl’.

Vous pouvez arrêter la session R en cours (q()), installer la dépendance (yum install openssl-devel), rouvrir la session R (/opt/R-devel/bin/R) et réexécuter les commandes R ci-dessus.

Après l’installation, vous pouvez lancer les “check” et essayer de trouver la source des erreurs rencontrées !

Sauvegarder l’état actuel du conteneur pour une utilisation ultérieure

Si vous arrêtez votre session, tout sera perdu. Vous devrez recommencer depuis le début et tout réinstaller.

Pour éviter un redémarrage complet, vous pouvez sauvegarder l’état actuel du conteneur en tant qu’image docker locale.

Ouvrez un nouveau Terminal. Trouvez le nom du conteneur en cours d’exécution (ici ecstatic_rosalind).

docker ps -a

CONTAINER ID   IMAGE                            COMMAND                   CREATED        STATUS                    PORTS     NAMES
f17796ecc57e   rhub/fedora-clang-devel:latest   "bash"                    4 hours ago    Exited (0) 2 hours ago              ecstatic_rosalind

Committez l’image avec un nouveau nom d’image (ici fedora-checkhelper). Remplacez ecstatic_rosalind par le nom de votre conteneur.

## commit the current running image to use for later
# docker commit ecstatic_rosalind fedora-checkhelper:latest

La prochaine fois, vous pourrez recommencer avec tous les paquets R que vous avez déjà installés, et continuer votre exploration avec :

# run container and mount your project inside
docker run -v /home/seb/checkhelper:/home/root/checkhelper -it fedora-checkhelper:latest bash

# Once inside, find and run R from "/opt"
/opt/R-devel/bin/R

Utiliser le plugin VSCode “Remote explorer” pour faciliter l’exploration

Dans mon exploration, j’ai choisi de travailler avec VSCode car il simplifie la connexion interactive à l’intérieur d’un conteneur en cours d’exécution. Cela permet de bénéficier de tous les plugins de VSCode à l’intérieur de votre conteneur, d’ouvrir interactivement vos fichiers R et de lancer votre commande avec un classique CTRL+ENTER.

Pour ce faire, vous devez avoir installé les plugins “Remote Explorer” et “Dev Containers”, ainsi que le plugin “Docker”.

Ouvrez un Terminal pour démarrer le conteneur.

docker run -v /home/seb/checkhelper:/home/root/checkhelper -it rhub/fedora-clang-devel:latest bash

Allez dans le menu de “Remote Explorer” et trouvez le conteneur en cours d’exécution dans la sous-liste “Dev Containers”.
Cliquez sur “Attacher à une nouvelle fenêtre”. Ne fermez pas le terminal que vous avez utilisé pour démarrer le conteneur.
Dans la nouvelle fenêtre, vous êtes à l’intérieur du conteneur Docker en cours d’exécution. Vous pouvez ouvrir le répertoire où votre projet est monté. Dans mon cas : “/home/root/checkhelper”.
A partir de là, vous pouvez ouvrir un Terminal (Menu Terminal > New Terminal).
Lancez /opt/R-devel/bin/R pour démarrer la session R.

Vous pouvez maintenant utiliser VSCode comme votre IDE habituel !

Si vous êtes perdu avec VSCode, vous pouvez lire mon précédent article sur Comment ne pas être perdu avec VSCode quand on vient de RStudio ?

A bientôt pour de nouvelles aventures !