Automate creation of dev environments and installation of R packages

[gueyenono]

First of all, many thanks to @b-rodrigues and @philipp-baumann for this package, which greatly flattens the steepness of the Nix learning curve for R users. This package is indeed a gem. The package is still young as of the time of writing this and the API is still in the process of stabilizing, but I would like to provide some suggestions for a probable future implementation:

1. A dedicated function for installing packages

From my understanding, installing a new R package in a Nix dev environment requires updating default.nix (using the rix::rix() function) and rebuilding the environment with it. Although the process is fairly simple, useRs may find it somewhat workflow-disrupting. It may be a good idea to add a new function to the rix package (à la renv::install()) which automates this process.

2. dedicated functions for creating specialized development environments

There are a few available specialized Docker containers for useRs depending on their main tasks. For example, the rocker project has a container for Shiny development and a container for geospatial analysis to name a few. There could be functions in rix which automate the building of such specialized dev environments. I discussed this suggestion with @b-rodrigues in private and he came up with rix_shiny() and rix_geos() as examples of what the functions could be named.

Given that one of the goals of rix is to greatly lower the entry cost to the world of Nix, I strongly believe that these suggestions fit right into that vision.

[b-rodrigues]

Hi @gueyenono , thanks these are useful suggestions!

I think I’d prefer something like rix::add() instead of install(), because technically, this would add packages to the already existing default.nix file and not directly install them. I think I’d prefer if the user still called rix::nix_build() afterwards, maybe.

As the other suggestion, we could see what these dedicated Docker images ship, and use that as a starting point to perhaps. It would definitely. I’m thinking of:

• rix_shiny()
• rix_geo()
• rix_litprog() (maybe with several options, such as a quarto environment, or rmarkdown, without or without latex or typst...)
• rix_tidyverse()
• rix_tidymodels() (but maybe that’s not really needed, since there’s already the tidyverse and tidymodels meta-packages that one can install)
• rix_python() (which would install reticulate and maybe some python packages ?)

[philipp-baumann]

Hi @gueyenono , thanks these are useful suggestions!

I think I’d prefer something like rix::add() instead of install(), because technically, this would add packages to the already existing default.nix file and not directly install them. I think I’d prefer if the user still called rix::nix_build() afterwards, maybe.

As the other suggestion, we could see what these dedicated Docker images ship, and use that as a starting point to perhaps. It would definitely. I’m thinking of:

* rix_shiny()

* rix_geo()

* rix_litprog() (maybe with several options, such as a quarto environment, or rmarkdown, without or without latex or typst...)

* rix_tidyverse()

* rix_tidymodels() (but maybe that’s not really needed, since there’s already the tidyverse and tidymodels meta-packages that one can install)

* rix_python() (which would install reticulate and maybe some python packages ?)

@b-rodrigues @gueyenono I also like idea 1) and 2); for 1), we just need to make sure that it doesn't require to excessive parsing (check if it's worth it, before we write too much code). JSON, what {renv} uses, is quite simpler structure-wise (however, less potent) -- but easier to parse/deparse; plus for nix we have the entire formatting and language aspects of nix (currently we still have some room to adjust formatting, mainly tidy indenting, in generated .nix file). @gueyenono i also think you are bringing up interesting aspects, which will help us to better communicate how the nix approach differentiates from {renv}. The main advantage is really that through nix {rix} we can resolve almost all linked libraries (CRAN, Bioconductor packages), and on top resolve most problems that arise from shipping project code across UNIX flavors.