¿Por qué y cuándo crear un paquete R?

Entiendo que esta pregunta es bastante amplia, pero me pregunto cuáles deberían ser los puntos decisivos para decidir crear (o no) un nuevo paquete para R. Para ser más específico, agregaría que la pregunta no se trata de las razones para use R en sí mismo, más sobre la decisión de compilar varios scripts e integrarlos en un nuevo paquete.

Entre los puntos que podrían conducir a estas decisiones, he pensado (de una manera bastante no exhaustiva), en:

• la inexistencia de otros paquetes en el mismo subcampo;
• la necesidad de intercambiar con otros investigadores y permitir la reproducibilidad de los experimentos;

Y entre los puntos que podrían conducir a una decisión contraria:

• parte de los métodos utilizados ya presentes en algunos otros paquetes;
• El número de nuevas funciones no es suficiente para justificar la creación de un nuevo paquete independiente.

Podría haber olvidado muchos puntos que podrían ir en cualquier lista, y también, estos criterios parecen parcialmente subjetivos. Entonces, ¿qué diría que debería justificar, y en qué punto, comenzar a reunir varias funciones y datos en un nuevo paquete documentado y ampliamente disponible?

No programo en R, pero programo lo contrario, y no veo ningún problema específico de R aquí.

Me imagino que la mayoría de las personas primero escriben algo porque realmente lo quieren para sí mismas. Por el contrario, cualquier sentimiento de que uno debería estar publicando software porque es lo que hay que hacer debe resistirse con fuerza. Las personas inteligentes pueden ser pésimos programadores, y a menudo lo son.

Hacer público parece ser una cuestión de confianza en que tiene algo que es tan bueno o mejor que lo que ya es público y llena un vacío. Saber que otras personas quieren hacer lo mismo seguramente es un impulso.

Si tiene dudas, no publique. En muchas comunidades, existe un problema de control de calidad de software mediocre o con errores lanzado por programadores no críticos o sin experiencia, aunque lo grave que es el problema permanece abierto al debate. Los optimistas creen que las curiosidades pueden ignorarse y que los usuarios expondrán errores y limitaciones lo suficientemente rápido; los pesimistas sienten que nos estamos ahogando en cosas de baja calidad y es difícil distinguir a los ganadores de los perdedores. (Por otro lado, la experiencia obtenida de la publicación es parte de lo que permite a los programadores mejorar).

Podría haber un libro sobre esto, pero se me ocurren algunos consejos:

1. La documentación de buena calidad distingue el buen software y el buen código, de hecho, a veces, de manera más obvia. Nunca subestimes cuánto trabajo se necesitará para proporcionar la documentación que merece el código. Los programadores de R a menudo parecen requerir que los usuarios de R sepan lo mismo que saben sobre la técnica que se está implementando y documenten mínimamente ...

2. En la medida de lo posible, pruebe su código para poder reproducir soluciones publicadas con datos reales de otros lugares. (Si está codificando algo totalmente nuevo, eso puede ser más difícil, pero no imposible. Además, a menudo se preguntará si es su error o el suyo).

3. Los programadores a menudo subestiman la capacidad de los usuarios para arrojar datos inadecuados a un programa. Entonces, piense en lo que podría salir mal, por ejemplo, con valores faltantes, ceros si un programa asume positivo, etc., etc. (La idea benigna aquí es que es tarea de los usuarios encontrar los problemas y mejorar el código a través de sus comentarios , pero un programa que se descompone fácilmente no mejorará su reputación).

Esta es una pregunta importante y práctica. Comencemos por distinguir entre escribir un paquete y publicarlo en CRAN.

Razones para no escribir un paquete:

• Eficiencia de costo.
• Falta de experiencia.

Razones para escribir un paquete R:

• Compartir con personas y plataformas.
• Fuerza un código ordenado y un proceso de trabajo.
• Facilidad de uso (incluso para uno mismo) cuando las funciones comienzan a acumularse.

Razones para enviar un paquete (CRAN, Bioconductor, ...):

• Contribución a la comunidad.
• Facilidad de distribución.

Recuerde que hay una opción # 3; puede pedirle al responsable de un paquete relevante que incluya su código o datos.

Mis disparadores personales para el empaque son:

• Me parece que nuevamente estoy usando algún código que escribí una vez para otro proyecto de análisis de datos.
• Creo que necesitaré el método que acabo de escribir nuevamente.

• Un colega me pide el código. Una parte sustancial del código que escribo es al menos tanto a pedido de colegas (que usan R pero no programan tanto) como para mí.

• Uso los requisitos formales de un paquete (documentación) para "obligarme" a limpiar y documentar mi código.

Estoy de acuerdo con @JohnRos en que hay una gran diferencia entre escribir un paquete y publicarlo.

• Usualmente empaco temprano, pero luego hago el paquete solo "semipúblico". Es decir, puede estar disponible en un servidor interno (o en r-forge), para que mis colegas puedan acceder al paquete. Pero publico en CRAN solo después de que el paquete ha sido utilizado durante meses o incluso algunos años por colegas cercanos. Esto no muestra todos los errores de acuerdo con el punto n. ° 3 de @Nick Cox, pero una buena cantidad de ellos.
  Las versiones del paquete (pongo la fecha después del guión en el número de versión) hacen que sea fácil arreglar las cosas ("para hacer esto y aquello, asegúrese de instalar al menos la versión de la semana pasada")

• Según mi contrato de trabajo, mi empleador tiene la última palabra sobre la decisión de si un paquete puede ser publicado en el mundo exterior y de qué manera.

Lo que aún no tengo una buena estrategia para empaquetar son los datos.

Comentarios a su lista de razones:

• la inexistencia de otros paquetes en el mismo subcampo;

No encontrar un paquete que haga lo que necesito para mí provoca la escritura del código, pero no tiene que ver con la decisión de empaquetar o no.

• la necesidad de intercambiar con otros investigadores y permitir la reproducibilidad de los experimentos;

Definitivamente Posiblemente ya sea la necesidad de compartir entre varias computadoras que uso.

Y entre los puntos que podrían conducir a una decisión contraria:

• parte de los métodos utilizados ya presentes en algunos otros paquetes;

podría importar esos métodos en su paquete / código: este es un punto en contra de escribir dicho código, pero solo tiene que ver indirectamente con el empaquetado.

• El número de nuevas funciones no es suficiente para justificar la creación de un nuevo paquete independiente.

Para mí, no hay un número mínimo de funciones para iniciar un paquete. En mi experiencia, los paquetes tienden a crecer "automáticamente". Por el contrario, después de encontrarme varias veces ramificando un nuevo paquete de otro (porque, por ejemplo, algunas funciones auxiliares al final resultaron ser temáticamente diferentes y útiles en otras situaciones también), ahora estoy bastante creando nuevos paquetes de inmediato.

Además, si no escribió documentación y pruebas, esto puede ser una cantidad prohibitiva de trabajo cuando se acumuló un número "suficiente" de funciones para crear un paquete.
(Si los escribe de inmediato, el esfuerzo adicional de incluirlo en un paquete es insignificante una vez que conoce el flujo de trabajo).

Yo diría que cree un paquete cada vez que esté haciendo un conjunto suficientemente grande de tareas similares en R que se beneficiaría de un paquete en el que puede colocar cosas en un espacio de nombres (para evitar conflictos con funciones con nombres similares), donde puede escribir documentación. Incluso tengo un paquete en github para agrupar una bolsa de funciones que no están relacionadas, pero las uso con tanta frecuencia que pensé que merecían documentación, archivos man, etc.

Otro caso de uso podría ser al enviar un documento, si tiene varias funciones, podría crear fácilmente un paquete, incluida la documentación para esas funciones, ejemplos para cada función y un tutorial sobre cómo usarlo. Y no necesita ponerlo en CRAN, como se dijo en las respuestas anteriores. Esto podría ser increíble para la reproducibilidad.

Tres herramientas que diría son importantes:

• devtools pkg , para que sea muy fácil crear paquetes (también vea el wiki en las páginas de devtools github
• paquete roxygen2 , para facilitar la escritura de documentación para su paquete
• GitHub, puede usar install_github(o similar install_bitbucket, etc.) para instalar directamente desde GitHub, lo cual es bueno para compartir con otros.

Estoy de acuerdo con todo lo que leí hasta ahora. Todas esas razones son buenas prácticas de programación y no se aplican a R en particular. Sin embargo, me encuentro escribiendo paquetes R la mayor parte del tiempo, y por otra razón más. Entonces agregaré:

Razón específica de R para escribir un paquete R:

• porque escribes en C

Cada vez que usa idiomas extranjeros como C, C ++ o FORTRAN (principalmente para computación de alto rendimiento), escribir un paquete vale la pena. Si tiene más de una o dos funciones, terminará rápidamente con archivos por todas partes y dependencias entre el código R y C que es difícil de mantener y portar.

Una razón no mencionada en las otras excelentes respuestas: tiene un proyecto de análisis de datos grande o complejo. Empaquetando, primero, los datos como un paquete, y luego extendiéndolos con funciones útiles para transformar, trazar o calcular análisis específicos. De esta forma, obtiene una versión documentada de los datos completa con todas las funciones utilizadas para calcular el análisis informado. Luego, los informes del proyecto pueden redactarse utilizando knitr u otros paquetes para una investigación reproducible.

Esto podría ahorrar significativamente tiempo si se debe realizar un nuevo análisis, o incluso podría publicarse (o semipublicarse) si se publican los análisis.