Hacker News Reader

Comment by fbdab103 | Hacker News Reader

>Tried putting R into production recently? It’s a frustrating and brittle experience.

Oh man, can I sign onto this rant. While Python has spent a decade+ trying-and-failing to standardize on one of a dozen tools to properly manage dependencies, at least it is trying. R is still global-namespace, no-pinning by default. Sorta-kinda you can squint where renv is going, but still needs a lot of development.

I had some hopes of Julia stealing the R mindshare and righting some of the more egregious wrongs in that ecosystem, but (as an outsider) it feels like Julia has lost a lot of steam.

View on HN

I find it really painless to put bits of R into production using the Nix support: https://nixos.org/manual/nixpkgs/stable/#r

The same framework can provide an identical-to-production R or RStudio environment for development.

I have a harder time with Julia since its tooling is more opinionated. I don't know a better solution than wrapping it in a Docker container.

If the cure for R is that I need to jump fully into the Nix ecosystem, I am not sure that is a solution.

Disappointing about Julia. Only played with it a small bit, but I had assumed it had identified dependency management as a huge problem that needed to be addressed.

Julia’s package management is miles ahead of R, and bests Python’s on a large number of factors. However the last time I used it, it still required you to issue commands into the repl to setup your packages. However, that might have been resolved by now? The language and tooling clips along at a pretty good pace.

You can now set up a Julia environment non-interactively from the command line by running:

    julia --project=. -e 'import Pkg; Pkg.instantiate()'

Not as clean as running

    python -m pip install -r requirements.txt

but it's something.

I find the flexibility of being able to setup and switch environments from within the REPL very enabling, and the Python approach of using the command-line shell feels kinda messy and cobbled together to me. (I felt this way about the Python approach before I even came across Julia, by the way.)

That said, there is a command-line utility jlpkg [1] that makes package management available from the shell. It's not very widely used, but maybe it suits your needs.

Although, the way you phrased

> it still required you to issue commands into the repl to setup your packages

makes me think maybe you didn't know about the Pkg mode in the REPL, and assumed you had to do everything with commands like `Pkg.add("DataFrames"); Pkg.update()` and such? If so, there's a package management mode to the REPL you can access with the ] key, which is kind of its own subshell within the REPL where you can do `add DataFrames`, `update`, and such instead.

[1] https://github.com/fredrikekre/jlpkg

I’m well aware of pkg mode in the repl, wasn’t aware of jlpkg though, that seems good.

> Oh man, can I sign onto this rant.

Please, be my guest hahaha.

I think my issue with so many of these tools is that they’re fundamentally meant to be used interactively. R (renv/etc) doesn’t have a package manager separate from the runtime, so you can’t just “yarn/pip/cargo/etc install” and have your dependencies setup prior to your script running, you have to invoke manual R commands and hope everything goes off ok, it doesn’t spontaneously pick a different directory to install your stuff in, or have a tantrum about permissions because it wants to install in some root dir.

Just use renv (successor of packrat). I had multiple versions of R working with multiple versions of Shiny running in production.

As I alluded to, renv exists, but it requires a lot of development work before it is a comparably robust option for the ecosystem. Basic things like a command-line interface [0], working with non-CRAN repos [1], using an existing DESCRIPTION file [2], etc. There are many use cases where renv does not work in a corporate environment (ie not open-source all public code scenarios). Some of those issues have been open for years.

I do not believe the situation is unsolvable, but there is significant work to be done. Renv provides value today, and I will encourage everyone to use it. However, it has significant blind spots which continue to make R deployments challenging.

[0] https://github.com/rstudio/renv/issues/1055 [1] https://github.com/rstudio/renv/issues/471 [2] https://github.com/rstudio/renv/issues/233

Reply on news.ycombinator.com