Pourquoi et quand créer un package R?

28

Je comprends que cette question est assez large, mais je me demande quels devraient être les points décisifs pour décider de créer (ou non) un nouveau package pour R. Pour être plus précis, j'ajouterais que la question ne porte pas sur les raisons de utiliser R en soi, plus sur la décision de compiler divers scripts et de les intégrer dans un nouveau package.

Parmi les points qui pourraient conduire à ces décisions, j'ai pensé (de façon assez non exhaustive):

  • l'inexistence d'autres packages dans le même sous-domaine;
  • la nécessité d'échanger avec d'autres chercheurs et de permettre la reproductibilité des expériences;

Et parmi les points qui pourraient conduire à une décision contraire:

  • une partie des méthodes utilisées déjà présentes dans certains autres packages;
  • nombre de nouvelles fonctions insuffisantes pour justifier la création d'un nouveau package indépendant.

J'aurais peut-être oublié de nombreux points qui pourraient entrer dans l'une ou l'autre liste, et aussi, ces critères semblent en partie subjectifs. Alors, que diriez-vous devrait justifier, et à quel moment, commencer à rassembler diverses fonctions et données dans un nouveau package documenté et largement disponible?

Camps Jean-Baptiste
la source

Réponses:

17

Je ne programme pas en R, mais je programme autrement, et je ne vois aucun problème spécifique à R ici.

J'imagine que la plupart des gens écrivent d'abord quelque chose parce qu'ils le veulent vraiment pour eux-mêmes. Inversement, tout sentiment de publier un logiciel parce que c'est la chose à faire doit être fortement combattu. Les gens intelligents peuvent être de mauvais programmeurs, et le sont souvent.

Rendre public semble être une question d'avoir confiance que vous avez quelque chose d'aussi bon ou meilleur que ce qui est déjà public et comble une lacune. Savoir que d'autres personnes veulent faire la même chose est certainement un coup de pouce.

En cas de doute, ne publiez pas. Dans de nombreuses communautés, il existe un problème de contrôle de la qualité des logiciels médiocres ou bogués publiés par des programmeurs non critiques ou inexpérimentés, bien que la gravité du problème reste sujette à débat. Les optimistes estiment que les anecdotes peuvent simplement être ignorées et que les utilisateurs exposeront les bogues et les limitations assez rapidement; les pessimistes pensent que nous nous noyons dans des trucs de mauvaise qualité et il est difficile de distinguer les gagnants des perdants. (D'un autre côté, l'expérience acquise grâce à la publication fait partie de ce qui permet aux programmeurs de s'améliorer.)

Il pourrait y avoir un livre à ce sujet, mais quelques conseils me viennent à l'esprit:

  1. Une documentation de bonne qualité distingue un bon logiciel ainsi qu'un bon code, en effet parfois de manière plus évidente. Ne sous-estimez jamais la quantité de travail qui sera nécessaire pour fournir la documentation que le code mérite. Les programmeurs R semblent souvent exiger que les utilisateurs R en sachent autant sur la technique mise en œuvre et documentent le moins possible ...

  2. Dans la mesure du possible, testez votre code afin de pouvoir reproduire des solutions publiées avec des données réelles d'ailleurs. (Si vous codez quelque chose de totalement nouveau, cela peut être plus difficile, mais pas impossible. En outre, vous pouvez souvent vous demander si c'est leur bug ou le vôtre.)

  3. Les programmeurs sous-estiment souvent la capacité des utilisateurs à envoyer des données inappropriées à un programme. Alors, pensez à ce qui pourrait mal tourner, par exemple avec des valeurs manquantes, des zéros si un programme suppose positif, etc., etc. (La bénédiction ici est que c'est le travail des utilisateurs de trouver les problèmes et d'améliorer le code grâce à leurs commentaires , mais un programme qui se décompose facilement n'améliorera pas votre réputation.)

Nick Cox
la source
1
Je ne pourrais pas être plus d'accord avec ces trois points (bien que le point 2 ne s'applique pas dans mon cas particulier, puisque j'ai conçu la méthode en question). Le troisième point est très important, et pose plus généralement la question du niveau d'information que l'on peut attendre de l'utilisateur (ou: pour qui publions-nous un package): faut-il coder uniquement pour des spécialistes du domaine, familiers avec la méthode à portée de main, ou essayez de rendre notre package utilisable par les chercheurs intéressés qui n'ont pas lu tous les articles connexes?
Camps Jean-Baptiste
2
# 2 s'applique toujours jusqu'à "tester votre code"! Différentes personnes ont des styles différents sur le dernier point, et il n'y a pas de bonne réponse. Vous pourriez penser que ce n'est pas le travail d'un programmeur d'expliquer ce qui est bien expliqué ailleurs, ou inutile de documenter un programme sauf en expliquant son utilisation. Dans la communauté Stata, où je suis actif, une bonne documentation semble largement appréciée et son manque est une préoccupation, mais la communauté R doit avoir ses propres mœurs.
Nick Cox
sur la façon de distinguer les gagnants des perdants et vos points très valides: # 1: heureusement, il y a des points dans R que l'on peut facilement vérifier, et qui pointent vers une meilleure documentation que les pages d'aide formelles requises. Une vignette est-elle fournie ( sos::findFntrouve ce critère suffisamment important pour mettre cette information dans le tableau des résultats!)? Une démo? Une page web avec plus d'informations? Donne citationun papier ou un livre # 2 approprié, vous pouvez envoyer des exemples de données avec votre code, donc même s'il n'y a aucune autre implémentation, vous pouvez tester votre code, maintenant, d'autres peuvent tester leur implémentation par rapport au vôtre.
cbeleites prend en charge Monica
1
"Les programmeurs R semblent souvent exiger que les utilisateurs R en sachent autant sur la technique mise en œuvre et documentent de manière minimale ..." - Il est important de distinguer la documentation du code de la méthode statistique . La documentation R n'est absolument pas l'endroit idéal pour apprendre les méthodes statistiques. Même les vignettes supposent un certain niveau de sophistication. Trop de plaintes concernant une documentation minimale dans R reviennent vraiment à se plaindre que les documents ne sont pas une cuillère leur alimentant des connaissances statistiques.
joran
2
Les points de suspension ... étaient destinés à signaler un tordu de côté. Il appartient à la communauté R de fixer ses propres normes, ou du moins d'en débattre.
Nick Cox
14

Il s'agit d'une question importante et pratique. Commençons par distinguer entre écrire un package et le publier sur CRAN.

Raisons de ne pas écrire de package:

  • Rapport coût-efficacité.
  • Manque d'expérience.

Raisons d'écrire un package R:

  • Partage avec les personnes et les plateformes.
  • Force un code bien rangé et un processus de travail.
  • Facilité d'utilisation (même pour soi) lorsque les fonctions commencent à s'accumuler.

Raisons de soumettre un dossier (CRAN, Bioconducteur, ...):

  • Contribution à la communauté.
  • Facilité de distribution.
JohnRos
la source
7
J'ajouterais que le manque d'expérience est également une raison pour écrire un package R. Écrire un package pour la première fois est non seulement amusant et difficile, mais il aide en fait à formuler des idées sur la façon de concevoir un package «approprié» qui sera utile à soi-même et à la communauté. En d'autres termes, même si l'on manque d'expérience, c'est toujours une bonne idée d'écrire un package afin d'acquérir de l'expérience en le faisant.
Graeme Walsh
1
Votre opinion, Grame, est assez motivante pour un programmeur R peu expérimenté qui hésiterait à concevoir un package. D'un autre côté, même si cela serait très certainement satisfaisant pour nous-mêmes, je note que les deux réponses soulignent (et je peux le comprendre également) la nécessité scientifique et de programmation d'un code propre, efficace et surtout sans erreur. Donc, cela ouvre une nouvelle question qui pourrait être "Comment s'assurer qu'un package R est exempt d'erreurs?", Censé être le travail de la communauté, mais le nombre croissant de nouveaux packages peut être une limite à cela.
Jean-Baptiste Camps
Cela revient définitivement à votre point de vue qu'il y a une grande différence entre écrire un package (par exemple, pour acquérir de l'expérience) et réellement passer à l'étape suivante et publier le package. cbeleites nous dit qu'il rend ses packages "semi-publics" et je pense que son approche contient des éléments sur la façon de s'assurer qu'un package R est exempt d'erreurs (ou plutôt, que la possibilité d'erreurs est minimisée). Essentiellement, une sorte de phase d'examen par les pairs ou de test est un moyen de s'assurer que les packages R sont de bonne qualité. Si trop de paquets surgissent sans examen, ils peuvent ne pas être aussi utiles.
Graeme Walsh
12

N'oubliez pas qu'il existe l'option n ° 3; vous pouvez demander au responsable d'un package pertinent d'inclure votre code ou vos données.


la source
8

Mes déclencheurs personnels pour l'emballage sont:

  • Je trouve que j'utilise à nouveau du code que j'ai écrit une fois pour un autre projet d'analyse de données.
  • Je pense que j'aurai besoin de la méthode que je viens d'écrire à nouveau.
  • Un collègue me demande du code. Une partie substantielle du code que j'écris est au moins autant à la demande de collègues (qui utilisent R mais ne programment pas beaucoup eux-mêmes) que pour moi.

  • J'utilise les exigences formelles d'un package (documentation) pour me "forcer" à nettoyer et à documenter mon code.

Je suis d'accord avec @JohnRos qu'il y a une grande différence entre écrire un package et publier le package.

  • J'empaquetage habituellement tôt, mais fais alors le paquet seulement «semi-public». Autrement dit, il peut être disponible sur un serveur interne (ou sur r-forge), afin que mes collègues puissent accéder au package. Mais je ne publie sur CRAN qu'après que le package a été utilisé pendant des mois, voire quelques années, par des collègues proches. Cela n'évoque pas tous les bogues selon le point n ° 3 de @Nick Cox, mais une bonne partie d'entre eux.
    Les versions du package (j'ai mis la date après le tiret dans le numéro de version) facilitent la correction des choses ("pour faire ceci et cela, assurez-vous que vous avez installé au moins la version de la semaine dernière")

  • Selon mon contrat de travail, mon employeur a le dernier mot sur la décision de savoir si et comment un paquet peut être publié dans le monde extérieur.

La chose où je ne fais pas encore de bonne stratégie pour l'emballage, ce sont les données.


Commentaires sur votre liste de raisons:

  • l'inexistence d'autres packages dans le même sous-domaine;

Ne pas trouver un package qui fait ce dont j'ai besoin déclenche l' écriture du code, mais cela n'a pas à voir avec la décision de packager ou non.

  • la nécessité d'échanger avec d'autres chercheurs et de permettre la reproductibilité des expériences;

Définitivement. Peut-être déjà la nécessité de partager entre plusieurs ordinateurs que j'utilise.

Et parmi les points qui pourraient conduire à une décision contraire:

  • une partie des méthodes utilisées déjà présentes dans certains autres packages;

vous pouvez importer ces méthodes dans votre package / code: c'est un point contre l' écriture d'un tel code, mais n'a qu'indirectement à voir avec l'empaquetage.

  • nombre de nouvelles fonctions insuffisantes pour justifier la création d'un nouveau package indépendant.

Pour moi, il n'y a pas de nombre minimum de fonctions pour démarrer un package. D'après mon expérience, les packages ont tendance à croître "automatiquement". Au contraire, après m'être retrouvé à quelques reprises à dériver un nouveau paquet d'un autre (parce que, par exemple, certaines fonctions d'aide se sont avérées finalement différentes et utiles dans d'autres situations), je suis maintenant plutôt créer de nouveaux packages immédiatement.

De plus, si vous n'avez pas écrit de documentation et de tests, cela peut représenter un travail prohibitif lorsqu'un nombre "suffisant" de fonctions pour créer un package s'est accumulé.
(Si vous les écrivez immédiatement, l'effort supplémentaire de le mettre dans un package est négligeable une fois que vous connaissez le flux de travail).

cbeleites soutient Monica
la source
3
+1. Un autre bon moyen de rendre les packages semi-publics est de mettre la source du package sur GitHub - cela rend le code plus facile à trouver et encourage les autres à contribuer sans le polissage implicite d'un package sur CRAN.
Matt Parker
7

Je dirais que créer un package chaque fois que vous effectuez un ensemble suffisamment important de tâches similaires dans R que vous bénéficieriez d'un package dans lequel vous pouvez placer des choses dans un espace de noms (pour éviter les conflits avec des fonctions de nom similaire), où vous pouvez écrire Documentation. J'ai même un paquet sur github pour regrouper un sac à main de fonctions qui ne sont pas liées, mais j'utilise si souvent que je pensais qu'elles méritaient de la documentation, des fichiers man, etc.

Un autre cas d'utilisation pourrait être lors de la soumission d'un article, si vous avez un certain nombre de fonctions, vous pouvez facilement créer un package, y compris une documentation pour ces fonctions, des exemples pour chaque fonction et un tutoriel sur la façon de l'utiliser. Et vous n'avez pas besoin de le mettre sur CRAN, comme indiqué dans les réponses ci-dessus. Cela pourrait être génial pour la reproductibilité.

Je dirais que trois outils sont importants:

  • devtools pkg , pour le rendre super facile à construire des paquets (voir aussi le wiki sur les pages github de devtools
  • roxygen2 pkg , pour faciliter l'écriture de documentation pour votre paquet
  • GitHub, vous pouvez utiliser install_github(ou similaire install_bitbucket, etc.) pour installer directement à partir de GitHub, ce qui est agréable à partager avec les autres.
sckott
la source
5

Je suis d'accord avec tout ce que j'ai lu jusqu'à présent. Toutes ces raisons sont de bonnes pratiques de programmation et ne s'appliquent pas à R en particulier. Cependant, je me retrouve à écrire des packages R la plupart du temps, et pour une autre raison encore. J'ajouterai donc:

Raison spécifique à R d'écrire un package R:

  • parce que vous écrivez en C

Chaque fois que vous utilisez des langues étrangères telles que C, C ++ ou FORTRAN (principalement pour le calcul haute performance), l'écriture d'un package en vaut largement la peine. Si vous avez plus d'une ou deux fonctions, vous vous retrouvez rapidement avec des fichiers partout et des dépendances entre le code R et C qui sont difficiles à maintenir et à porter.

gui11aume
la source
0

Une raison non mentionnée dans les autres excellentes réponses: vous avez un projet d'analyse de données volumineux ou complexe. Empaquetez d'abord les données sous forme de package, puis étendez-les avec des fonctions utiles pour transformer, tracer ou calculer des analyses spécifiques. De cette façon, vous obtenez une version documentée des données avec toutes les fonctions utilisées pour calculer l'analyse rapportée. Ensuite, le ou les rapports du projet peuvent être rédigés à l'aide de knitr ou d'autres packages pour une recherche reproductible!

Cela pourrait considérablement gagner du temps si une nouvelle analyse doit être effectuée, ou elle pourrait même être publiée (ou semi-publiée) si l'analyse est publiée.

kjetil b halvorsen
la source