[claytonjy]

Despite having switched to Python after many years of being a tidyverse acolyte, I don't really understand this argument against deployed R.

Are folks who say this not using containers? R has been at least as easy to dockerize as Python since whenever Rocker started, only easier with more recent package management options. Once dockerized, my only R complaints are around logging inconsistencies.

I used to think the culture around R meant that productionizing arbitrary code was harder on average than in Python...but years of suffering with the pandas API has me thinking the opposite these days.

I can trust a junior R dev to write reusable pure functions but can't trust a senior Python dev to do the same!

[hfmuehleisen]

DuckDB also works fine with R data frames so there is really no downside to using R in this case

[Dayshine]

For one, in my experience, CRAN only stores binaries of the most recent release of each package. This means that either you have to accept you can never rebuild a docker image, or you have to make sure that you are always able to recompile all of your R packages from source.

This means you don't just have to pin your R package versions, you have to pin all the build dependencies.

And you have to have a different image for different sets of R packages because they might have different build dependencies.

[claytonjy]

Reproducibility is of course a valid concern, but I never had issues with that thanks to Rocker and MRAN.

I do sympathize with long from-source build times; as a Linux user I don't think I had binaries available until I stopped using R, so I've spent days, perhaps weeks, waiting for dplyr to install over the course of my R usage.

> different image for different sets of R packages because they might have different build dependencies

Is this not true of all software in all languages?