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

Question

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

Entre los puntos que podrían llevar a estas decisiones, he pensado (de forma 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 llevar a una decisión contraria :

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

Puede que haya olvidado muchos puntos que podrían ir en cualquiera de las dos listas, y además, estos criterios parecen en parte subjetivos. Entonces, ¿qué diría usted que debería justificar, y en qué momento, el empezar a reunir diversas funciones y datos en un nuevo paquete documentado y ampliamente disponible?

Answer 1

Yo no programo en R, pero programo de otra manera, y no veo ningún problema específico de R aquí.

Imagino que la mayoría de la gente primero escribe algo porque realmente lo quiere para sí misma. A la inversa, hay que resistirse firmemente a cualquier sensación de que uno debe publicar software porque es lo que hay que hacer. Las personas inteligentes pueden ser pésimos programadores, y a menudo lo son.

Hacerlo público parece una cuestión de confianza en que se tiene algo que es tan bueno o mejor que lo que ya es público y que llena un vacío. Saber que otras personas quieren hacer lo mismo es sin duda un estímulo.

Si tienes dudas, no publiques. En muchas comunidades existe un problema de control de calidad de software mediocre o con errores publicado por programadores poco críticos o inexpertos, aunque la gravedad del problema está abierta al debate. Los optimistas creen que las trivialidades pueden ignorarse y que los usuarios sacarán a la luz los fallos y las limitaciones con la suficiente rapidez; los pesimistas creen que nos estamos ahogando en material de baja calidad y que es difícil distinguir a los ganadores de los perdedores. (Por otro lado, la experiencia adquirida con la publicación es parte de lo que permite a los programadores mejorar).

Podría haber un libro sobre esto, pero se me ocurren algunas indicaciones:

1. Una documentación de buena calidad distingue al buen software tanto como al buen código, de hecho a veces de forma más evidente. Nunca hay que subestimar el trabajo necesario para proporcionar la documentación que el código merece. Los programadores de R a menudo parecen exigir que los usuarios de R sepan tanto como ellos sobre la técnica que se implementa y documentan mínimamente....

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

3. Los programadores suelen subestimar la capacidad de los usuarios para arrojar datos inadecuados a un programa. Por lo tanto, piensa en lo que podría salir mal, por ejemplo, con valores perdidos, ceros si un programa asume positivo, etc., etc. (La toma benigna aquí es que es el trabajo de los usuarios para encontrar los problemas y mejorar el código a través de sus comentarios, pero un programa que se rompe fácilmente no mejorará su reputación).

Answer 2

Esta es una cuestión importante y práctica. Empecemos por distinguir entre escribir un paquete y publicarlo en CRAN.

Razones no para escribir un paquete:

• Eficiencia de costes.
• Falta de experiencia.

Razones para escribir un paquete R:

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

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

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

Answer 3

Recuerde que existe la opción #3; puede pedir al mantenedor de un paquete relevante que incluya su código o datos.

Answer 4

Mis desencadenantes personales de los envases son:

• Me encuentro con que vuelvo a utilizar un código que escribí una vez para otro proyecto de análisis de datos.

• Creo que voy a necesitar el método que acabo de escribir de nuevo.

• Un colega me pide un código. Una parte importante del código que escribo es, al menos, a petición de los colegas (que usan R pero no programan mucho ellos mismos) como para mí mismo.

• Utilizo 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 bastante diferencia entre escribir un paquete y publicar el paquete.

• Suelo empaquetar antes, pero luego hago que el paquete sea sólo "semipúblico". Es decir, puede estar disponible en un servidor interno (o en r-forge), para que mis colegas pueden acceder al paquete. Pero lo publico en CRAN sólo después de que el paquete haya sido utilizado durante meses o incluso algunos años por colegas cercanos. Esto no saca a la luz todos los bugs según el punto #3 de @Nick Cox, pero sí una buena cantidad de ellos.
  Las versiones del paquete (pongo la fecha después del guión en el número de versión) facilitan el arreglo de las cosas ("para hacer esto y aquello, asegúrate 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 publicarse al exterior y cómo.

La cosa en la que hago no sin embargo, tener una buena estrategia para el empaquetado es un dato.

---

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í dispara escribir el 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 la necesidad de compartir entre varios ordenadores que uso.

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

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

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

• número de funciones nuevas 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 haberme encontrado unas cuantas veces ramificando un nuevo paquete a partir de otro (porque, por ejemplo, algunas funciones de ayuda al final resultaron ser temáticamente diferentes y útiles también en otras situaciones), ahora prefiero crear nuevos paquetes inmediatamente.

Además, si no has escrito la documentación y las pruebas, esto puede suponer una cantidad de trabajo prohibitiva cuando se acumula un número "suficiente" de funciones para crear un paquete.
(Si los escribes inmediatamente, el esfuerzo adicional de ponerlo en un paquete es insignificante una vez que conoces el flujo de trabajo).

Answer 5

Yo diría que hay que crear un paquete siempre que se haga un conjunto lo suficientemente grande de tareas similares en R como para beneficiarse de un paquete en el que se puedan poner las cosas en un espacio de nombres (para evitar conflictos con funciones de nombre similar), donde se pueda escribir la documentación. Incluso tengo un paquete en github para agrupar una bolsa de funciones que no están relacionadas, pero que uso tan a menudo que pensé que merecían documentación, archivos man, etc.

Otro caso de uso podría ser al presentar un trabajo, si tienes un número de funciones podrías crear fácilmente un paquete, incluyendo la documentación para esas funciones, ejemplos para cada función, y un tutorial sobre cómo usarlo. Y no es necesario ponerlo en CRAN, como se dice en las respuestas anteriores. Esto podría ser impresionante para la reproducibilidad.

Hay tres herramientas que yo diría que son importantes:

• paquete devtools para facilitar la creación de paquetes (véase también el wiki en las páginas de github de devtools)
• paquete roxygen2 para facilitar la redacción de la documentación de su paquete
• GitHub, puede utilizar install_github (o similarmente install_bitbucket, etc.) para instalar directamente desde GitHub, lo cual es bueno para compartir con otros.