2012-02-16 8 views
15

¿Existe un recurso de comunidad R estándar para mantenerse al día con errores conocidos o soluciones de errores para paquetes? Mi enfoque actual es más bien manual. (NB: estoy restringiendo esto a CRAN - ver Nota 1.)¿Cómo mantenerse al tanto de los errores conocidos y las correcciones de errores en los paquetes R?

Mi caso de uso es básicamente la vigilancia de errores y la administración de actualizaciones de paquetes. He estado promediando un par de descubrimientos de errores cada mes por un tiempo (que informo debidamente a los autores ;-)). Dado que gran parte de mi trabajo se realiza con máquinas virtuales, tiendo a actualizar las imágenes de VM cuando tengo un buen manejo del estado de la falla para los paquetes necesarios. Cuando se resuelven un montón de errores, puedo eliminar mis soluciones, lo cual es genial, y actualizo las imágenes. Cuando descubro un brote de errores, no creo una nueva imagen.

Aquí están las fuentes actualmente estoy usando:

  • archivos noticia: Muchos, pero no todos, los paquetes tienen archivos de noticias. Estos son ciertamente un lugar útil para comenzar.
  • Página de inicio del paquete: Algunos paquetes no tienen un archivo de noticias en CRAN, pero publican por separado un registro de cambios en el sitio del autor. listas de correo alojada en proyectos
  • R
  • Google Grupos de paquetes
  • comunicación personal con los autores del paquete
  • seguimiento de errores de paquetes (por ejemplo, un desarrollador puede utilizar Bugzilla)

Es una cosa es ser el primero en descubrir un error (reconozco que nos pasan errores a todos nosotros), y otro descubrir tardíamente un error que ya es conocido o, mejor aún, ya ha sido resuelto. Ambos ralentizan mi propia codificación, pero una mejor vigilancia de errores (tal vez necesitamos un paquete cdc4R :)) reduciría significativamente el impacto. Sin un sistema de alerta de actualización estándar (por ejemplo, una extensión a update.packages() que informa sobre qué paquetes podrían actualizarse y enlaces a información sobre lo que ha cambiado), es tarea del usuario buscar esta información.

Como tal usuario, tratando de buscar esta información, ¿hay algún recurso estándar que he pasado por alto en la lista anterior? Por ejemplo, ¿hay una lista de correo de R donde es común que los desarrolladores publiquen sus cambios y correcciones de errores? ¿O hay algún sitio que agregue tales publicaciones, publique pruebas (parece que CRAN publica R CMD CHECK), o que brinde algún otro comentario?


Algunas notas adicionales en otros recursos, para beneficio de los demás:

  • CRANberries veo que tiene un escueto resumen diff en los paquetes, lo que es nuevo para mí. (Estoy inspirado para considerar un grep para bug o fix en la salida diff.)
  • bug.report() en R es una buena manera de enviar un mensaje a R Core o la dirección de correo electrónico de un mantenedor de paquetes.
  • Varios paquetes de prueba que vale la pena considerar son: testthat, RUnit y svUnit.
  • Mi "prueba rápida" personal es simplemente usar digest para verificar que los resultados coincidan, sin tener que probar la igualdad de objetos muy grandes.

Nota 1: Estoy etiquetar este porque es imposible manejar el universo de todas las R paquetes. Para un autor de paquete individual, uno puede distribuir un paquete donde quiera, usar la lista de correo o el sistema de seguimiento de errores que prefiera, etc. Sin embargo, eso está fuera de la "corriente principal" de R. ¿Debo liberar un paquete y alertar a los usuarios? a cambios, errores, correcciones de errores, me gustaría ir con CRAN + NOTICIAS + Bugzilla + Grupos de Google + R-Forge (y/o RForge), etc., pero ¿hay otro mecanismo estándar de informes que falta en esta lista?

En cierto sentido, esta nota también sirve para preguntar si hay un mecanismo que los desarrolladores pueden usar. Sospecho que no existe un estándar, ya que los paquetes de los miembros de R Core parecen hacer muchas cosas diferentes con respecto a los errores y los informes de cambios.

Nota 2: También estoy agregando (aunque algo más puede ser más apropiado), ya que esto también se relaciona con la administración de R. Para la reproducibilidad, la administración de paquetes es bastante importante; cuando hay varios usuarios o más piezas en movimiento, estar al tanto de los errores y las correcciones se convierte en una tarea administrativa, así como una consideración importante para el desarrollo que depende de los paquetes externos. Si hay otra etiqueta, p. es más apropiado, estoy abierto a un cambio.

+1

esto debería ser de alguna manera una característica de CRAN, no debería ser? ¡CRAN debe conocer las actualizaciones, así que creo que debería tener algún canal RSS para ellas! ¡Coloque la solicitud de función en CRAN! ¿O el problema es distinguir si la actualización contiene correcciones de errores o no? – TMS

+0

@Tomas Estoy interesado en errores; es fácil verificar que los paquetes se hayan actualizado. Los errores son un tema diferente y requieren atención: puedo actualizar a una versión más nueva, volver a una versión anterior o trabajar en torno a ellos, si tienen un impacto en mi trabajo. Otros cambios en el código, como el rendimiento o los cambios en la interfaz, exigen menos atención inmediata en un sistema que ya funciona. – Iterator

+0

No creo que se haya perdido nada importante. Yo uso github para todos mis paquetes, por lo que los problemas NEWS + github son los mejores lugares para buscar. – hadley

Respuesta

3

No es una respuesta completa, pero aquí hay algunas ideas.

En el caso de data.table rastreamos errores (y solicitudes de características) on R-Forge here. Me imagino que podrías consultar el rastreador de R-Forge (programáticamente) para todos los paquetes alojados allí. Para agregar a tu lista de todos modos. Ese rastreador web es donde apunta bug.report(package="data.table") (no solo una dirección de correo electrónico para el mantenedor).

Además, cualquiera puede suscribirse a cualquier lista de correo <pkgname>[email protected] para recibir un mensaje unificado de diferencia y confirmación (en el momento de la confirmación) para cada proyecto en R-Forge. Sin embargo, no tengo conocimiento de una lista de correo general que abarque ningún compromiso con ningún proyecto de R-Forge.

En la parte superior de ?data.table hay un enlace a up to the minute NEWS. Así es como comunicamos a los usuarios qué hay en la última versión (y en desarrollo) si se actualizan. Ese enlace se actualiza en tiempo real; es decir, "hasta el minuto" significa literalmente. ¡Pero, tienen que verificar allí!

+0

Si bien el proyecto ha habilitado los correos electrónicos, ¿no? No creo que esté activado para todos los proyectos de R-Forge. Pero tal vez eso cambió ... –

+0

@Dirk Pensé que los compromisos se crean de forma predeterminada, pero el administrador del proyecto podría desactivarlo (bien puede estar mal). Sin embargo, no creo que nadie esté suscrito automáticamente, ni siquiera el administrador.Así que tal vez para los proyectos en los que nadie se ha suscrito: se compromete, no envía ningún mensaje, por lo que el archivo no se acumula hasta el primer compromiso después de la primera suscripción. Solo adivinando. –

+0

¡Gracias por las sugerencias! Su desarrollo de 'data.table' y la administración de informes y cambios es excelente y muy apreciado. Es uno de los paquetes de los que dependo, junto con las instalaciones de informes y seguimiento que utiliza. Me di cuenta de que no tenía los mismos recursos en otros paquetes y me preguntaba cómo podría abordar eso por mi cuenta. – Iterator

Cuestiones relacionadas