Este post está basado en hechos reales.

Varias veces cuando instalé la última versión de R, y prosegui a instalar todos los paquetes que tenía en la versión anterior, me he encontrado problemas. También aplica cuando actualizamos paquetes después de un tiempo.

Decidí hacer este post luego de ver la recepción de la comunidad a un posteo rápido que hice:

Este post no quiere desalentar la instalación de R, todo lo contrario, advertir el “lado oscuro” de la migración y hacer de nuestros proyectos algo estable en el tiempo.

Por suerte las funciones cambian para mejor, o incluso mucho mejor como es el caso de la suite del tidyverse.

☎️ Me encuentran linkedin y twitter.

💻 Si quieren aprender lo básico de R: Desembarcando en R 2da Edición (gratis), o ir a la versión paga con soporte mio y certificado, aquí!

---

Proyectos que no se ejecutan frecuentemente

Por ejemplo, post migración en la corrida para generar el Libro Vivo de Ciencia de Datos (escrito 100% en R markdown), me han aparecido mensajes de depreciación de función como warning. Naturalmente tengo que sacarlos o bien, usar la nueva función.

También tuve el caso en el que cambiaban algunos de los parámetros de R Markdown.

Otro caso 🎬

Imaginen el siguiente flujo sería: se instala R 4.0.0, luego la última versión de todos los paquetes. Tomando como ejemplo ggplot, pasamos de, 2.8.1 a la 3.5.1.

La versión 3.5.1 no tiene una función porque está deprecada, ergo falla. O incluso cambió una función (ejemplo del tidyverse: mutate_at, mutate_if). Cambia lo que se denomina la firma de la función, ej el parámetro '.vars'.

Instalación de paquetes

Bueno, si migramos y no instalamos todo lo que teníamos anteriormente, vamos a ejecutar un script viejo y tendremos este problema.

Algunos recomiendan listar todos los paquetes que tenemos instalados, y generar un script que los instale.

Otra solución es copiar a mano los paquetes de una carpeta de la vieja versión de R a la nueva. Los paquetes son carpetas dentro de la instalación de R.

R en servidores

Otro caso, tienen R instalado en un servidor con procesos que se ejecutan todos los días, hacen la migración y algunas de las funciones cambian su firma. Es decir, cambian el tipo de dato que quizás se definen en una función.

Este punto no debería ocurrir seguido si uno migra de versión de paquetes a menudo. El flujo normal para eliminar una función de un paquete de R es primer anunciar un con un warning el famoso `deprecated`: Mark a function as deprecated in customised R package.

Si el anuncio esta en una versión N+1, y nosotros pasamos de N a la versión N+2, quizás nos perdemos el mensaje y la función se deja de usar.

¿Entonces no se aconseja la actualización de paquetes y R?

Como comenté al principio, por supuesto que sí aconsejo la migración.

Hay que estar [email protected] y probar los proyectos que tenemos actualmente.

Sino, no tendríamos muchísimas de las facilidades que hoy día nos dan los lenguajes a través del uso de la comunidad. Ni siquiera es dependiente de R.

---

📝 Otro post que podría interesarte: Análisis Exploratorio de Datos con R (introducción)

---

Algunos consejos: Ambientes

Python tiene un concepto muy útil que es el de virtual environment, se crea rápido, y lo que ocasiona es que cada instalación de librerías se hace en la carpeta del proyecto.

Luego se hace `pip freeze > requirements.txt` y todas las librerías con su versión queda en un txt con el que pueden recrear rápidamente el ambiente con el que desarrollaban. [Why and How to make a Requirements.txt]

Esto no es tan fácil en R, existe packrat pero tiene sus complejidades, por ejemplo si hay repos en github.

Augusto Hassel recién me comentó sobre la librería renv (también de RStudio! 👏). Cito a la página:

“The renv package is a new effort to bring project-local R dependency management to your projects. The goal is for renv to be a robust, stable replacement for the Packrat package, with fewer surprises and better default behaviors.”

Pueden ver las slides de: renv: Project Environments for R, por Kevin Ushey.

Docker

Augusto también me comentó de Docker como solución:

“Usando Docker podemos encapsular el entorno necesario para correr nuestro código a través de un archivo con instrucciones llamado Dockerfile. De esta manera, siempre estaremos corriendo la misma imagen, donde sea que levantemos el entorno.”

Acá les dejo un post de su autoría: Mi Primer Repositorio en Docker

Conclusiones

✅Si tienen R en producción, tengan un entorno de testing y otro de productivo.

✅Instalen R, sus librerías, y luego revisen que todo siga corriendo como siempre.

✅Tengan unit test para probar automáticamente que no se rompa el flujo de datos. En R miren testthat.

✅Actualicen todas las librerías cada X meses, no dejen pasar mucho tiempo.

Como moraleja, esto también es ser data scientist, resolver problemas de versiones, instalación y ambientes.

---

Moss! ¿qué te pareció el post?

“Ahora si... me voy a instalar R 4.0.0!!”

---

📬 Escuela de Datos Vivos en Linkedin y Twitter | Curso gratuito Desembarcando en R 2da Edición.

🤔 ¿Dudas? Registrate gratis y dejá tu comentario