{checkhelper} est sur le CRAN : pour ne plus avoir peur de lancer un check

Vous avez fait un super package dont vous êtes fier·e et vous souhaitez le partager avec la communauté R ? Peut-être même le soumettre au CRAN ?

Avant celà, vous savez que quelques checks sont recommandés.. si si vous le savez ! mais devtools::check() vous renvoie 7 warnings, 12 notes et 200 lignes pas très claires alors…

Alors vous êtes au bon endroit ! Car nous sommes heureux de vous annoncer que la première version de notre package {checkhelper}, votre compagnon conçu pour vous faciliter le processus de vérification de votre package, est maintenant disponible sur CRAN !

C’est parti pour un plongeon dans les usages et fonctionnalités associées de {checkhelper}.

{checkhelper}, un compagnon pour tous les développeurs de packages R

La fonction devtools::check() est classiquement utilisée durant le développement d’un package pour effectuer des vérifications sur divers aspects tels que les erreurs de codage, les problèmes de documentation, et d’autres problèmes qui pourraient entraver la fonctionnalité d’un package. {checkhelper} a pour but de vous guider dans le traitement des sorties (parfois denses et nébuleuses) de cette fonction.

{checkhelper} est pensé pour vous faciliter l’identification et la résolution de problèmes au “check” dans votre package, souvent liés à de petits oublis… ça arrive à tout le monde !

{checkhelper} contient différentes fonctions vous facilitant la résolution de problèmes “classiques” du check(), comme par exemple :

• print_globals() renvoie le code contenant toutes les variables globales de votre package et indique comment le sauvegarder dans un fichier globals.R
• checkhelper::find_missing_tags() vous indique les problèmes de balises {roxygen2} (@return sans valeur pour une fonction exportée, fonction documentée sans balise @export ou @noRd)
• checkhelper::check_clean_userspace() vous indique les fichiers volants potentiellement créés lors du lancement de devtools::check() (sorties d’exemples, tests ou vignettes de votre package), et qui ne sont pas nettoyés après le passage du “check”. En particulier, ceux qu’on n’aime pas trop, ce sont les fichiers qui reste dans l’espace de travail de l’utilisateur…
• checkhelper::use_data_doc() crée automatiquement la documentation associée à des données inclues dans votre package aux formats .rda ou .RData

{checkhelper} est donc utile pour tous les développeurs de packages, car il aide à maintenir et à améliorer la qualité de leurs produits, qu’ils soient destinés ou non à être soumis au CRAN.

{checkhelper}, pour sauter le rempart qui sépare votre package du CRAN

Vous avez peut-être aussi pensé à publier votre package sur le Comprehensive R Archive Network, pour les intimes : CRAN. C’est un pas de plus pour rejoindre le rang des acteurs de la communauté R et aussi une meilleure visibilité pour votre travail.

Mais il est probable que devant la procédure de soumission vous ayez été un peu refroidi·e. Et oui ! le processus de soumission au CRAN, on l’aime quand on est du côté utilisateur car il garantit que le package soit bien documenté et fiable. Bref, un gage de qualité et de confiance. Mais quand on veut passer de l’autre côté du miroir, la préparation de la soumission peut faire un peu peur.

Heureusement, {checkhelper} est également là pour vous aider dans ce défi !

{checkhelper} contient une fonction expérimentale checkhelper::check_as_cran() qui utilise les configurations et scripts de “check” utilisés par le CRAN pour la machine Linux et que vous pouvez retrouver ici : https://github.com/r-devel/r-dev-web/tree/master/CRAN/.

Cette dernière vous permet donc de vérifier en local votre package avant sa soumission à CRAN, en veillant à ce que toutes les directives soient respectées, augmentant ainsi les chances d’acceptation.
Notez que cette fonction expérimentale, configurée pour Linux, ne saurait remplacer les envois sur les serveurs de {rhub} avec devtools::check_rhub(), ni les tests sur les serveurs du CRAN avec devtools::check_win_devel(), devtools::check_win_release() et devtools::check_mac_release()

Nous vous recommandons de suivre la liste des outils pour soumission au CRAN que nous maintenons dans notre dépôt GitHub : Preparing your package for a CRAN submission

{fusen} et {attachment}, d’autres alliés pour des checks réussis

Vous avez suivi les indications de {checkhelper} et vos checks ne passent pas au vert ?

Nos packages {fusen} et {attachment} sont aussi là pour faciliter vos développements de package et leur maintenance sur d’autres fronts !

{fusen} permet de rassembler dans un même fichier Rmarkdown ou Quarto le code source de vos fonctions, leurs documentations et tests associés. Le code se trouvant dans votre fichier Rmd est réparti dans les dossiers et fichiers ad hoc par {fusen}. Fini de perdre du temps à naviguer entre les fichiers durant le développement, donc moins d’erreurs, et surtout, on n’oublie pas d’écrire les tests unitaires ! D’ailleurs, le développement avec {fusen} est encore plus facile qu’avant car la dernière version de {fusen} permet de gérer tous les fichiers Rmd en même temps (voir notre article “Inflatez les tous !”).

{attachment} permet quant à lui de gérer plus facilement les dépendances de vos fonctions à d’autres packages. Et lui aussi s’est récemment payé un petit upgrade pour vous permettre d’écrire toujours moins de code rébarbatif tout en gardant un check au top ! (voir notre article {attachment} v0.4.0 : Des changements majeurs et un fichier de configuration pour une meilleure expérience)

Pour aller plus loin avec {checkhelper}

Vous pouvez retrouver {checkhelper} sur CRAN et sur GitHub pour sa version en développement

Pour lire la documentation complète du package {checkhelper}, vous pouvez suivre ce lien vers le site {pkgdown}.

D’autres fonctionnalités sont dans les tuyaux dans {checkhelper}, comme la possibilité de produire un “code coverage” en même temps que le “check”, sans exécuter deux fois les tests, afin de réduire le temps de calcul qui est parfois très long pour les gros packages. Si vous voulez participer à ces développements en rapportant des bugs ou en proposant des “pull requests”, RDV sur la page github de {checkhelper}.

Retrouvez nos autres contributions à l’open-source et à la communité R ici