Pourquoi et quand créer un package R?

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?

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.)

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.

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.

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).

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.

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.

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.