Rstudio

El 1 de marzo de 2011 escribí esto anunciando un nuevo IDE multiplataforma (¡qué falta hacía!) para R. Trece años más tarde, la misma empresa nos provee de otro bien público, Positron.

Aún no he podido instalar la beta pública en mi Archlinux por un conflicto con VS Code —sí, Positron parece ser un VS Code tuneado—, pero prometo una captura de pantalla una vez se arregle el asunto.

En tanto, ¿qué espero de Positron? No otra cosa que la facilidad que ofrece RStudio para el análisis informal e interactivo de datos. Ni los IDEs habituales ni los notebooks ofrecen un mecanismo ágil para la exploración: ambos están enfocados en ofrecer un producto final cerrado: un software que funcione en el primer caso, un documento en el segundo. Si Positron nos permite hacer con Python lo que RStudio con R —y lo que he visto por ahí apunta en esa dirección: Positron parece una reconstrucción de RStudio sobre una plataforma distinta—, el mundo será un poquito más bello.

Resumen:

• He decidido usar RStudio como IDE para Python. RStudio no es el mejor IDE para desarrollar, pero es incomparablemente mejor que cualquier otro IDE para explorar, etc. Funciona muy bien y solo puede mejorar.
• He decidido pasar de Jupyter. Los notebooks valen para lo que valen, pero no para lo que hago. En caso de necesidad, uso Rmarkdown con bloques de Python. De nuevo, funcionan muy bien y solo pueden mejorar.
• Finalmente, he decidido pasar de Anaconda. Tiene incompatibilidades con RStudio. Particularmente, cuando los módulos de Python tratan de cargar shared libraries. Los módulos de Anaconda tienen el vicio de buscarlos dentro del directorio de instalación, pero al lanzar el intérprete de Python a través de reticulate, en Linux parece que los busca en el sistema (por debajo de /usr/lib y similares). Y todo se rompe mucho. Mucho y muy, muy feo.

Así que uso los Python (3.7 cuando puedo, otras versiones cuando me obligan) del sistema. Pero la instalación del sistema es mínima. He creado varios environments ad hoc (y dentro de un directorio ad hoc para ellos) y obigo a reticulate a usarlos (vía use_virtualenv()) según conveniencia. En ellos tengo todas las dependencias (de numpy para arriba).

La solución que presenté el otro día para resolver el problema en cuestión, tal como indicó Iñaki Úcar, es demasiado aparatosa. La alternativa a mi propuesta

ssh -ND 2001 miusuario@datanalytics.com

y todo lo que sigue es crear un túnel ssh mediante

ssh -NL 2001:localhost:8787 miusuario@datanalytics.com

y conectarse a la sesión remota de RStudio apuntando en cualquier navegador a http://localhost:2001.

El comando anterior exige la debida exégesis, que nunca había tenido del todo clara. Lo que hace es, primero, crear una conexión entre mi ssh local, el ordenador en el que lanzo el comando, y mi ssh remoto (el servidor con nombre datanalytics.com). Eso es lo que verán los terceros: una conexión ssh entre dos máquinas.

Finalmente, instalé RStudio Server en la máquina que está sirviéndote esta página. Pero no dejo abierto el puerto 8787 al exterior ni jarto de vino.

(De hecho, veréis que desde hace un tiempo a este blog escucha en el puerto 443 y, aunque esa es otra historia, utiliza HTTP/2).

Así que lo he configurado para que solo se pueda acceder a él desde localhost, i.e., que no admita conexiones remotas, añadiendo la línea

Noticia fresca, recién salida del horno: RStudio acaba de salir a la luz. Se trata de un nuevo editor multiplataforma y de código abierto de R .

Está desarrollado en C++ y corre en Linux, Windows y Mac OS X. Y no puedo decir mucho más de momento. Pero espero los comentarios de todos los entusiastas de R al respecto.