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