removed mentions of remote packages not being handled by renv2nix

R/renv_helpers.R

@@ -123,10 +123,11 @@ renv_remote_pkgs <- function(
 #'   similar, an attempt is made to handle them and pass them to the `git_pkgs`
 #'   argument of `rix()`. Currently defaults to "fast", "accurate" is not yet
 #'   implemented.
-#' @param override_r_ver Character defaults to NULL, override the R version
+#' @param override_r_ver Character, defaults to NULL, override the R version
 #'   defined in the `renv.lock` file with another version. This is especially
 #'   useful if the `renv.lock` file lists a version of R not (yet) available
-#'   through Nix.
+#'   through Nix, or if the R version included in the `renv.lock` is too old
+#'   compared to the package versions.
 #' @inheritDotParams rix system_pkgs local_r_pkgs:shell_hook
 #'
 #' @return Nothing, this function is called for its side effects only, unless
@@ -136,14 +137,10 @@ renv_remote_pkgs <- function(
 #'   running it inside the same folder as an existing `{renv}` project. Instead,
 #'   run it from a new, empty directory which path you pass to `project_path`,
 #'   and use `renv_lock_path` to point to the `renv.lock` file in the original
-#'   `{renv}` folder. You can also start from an empty folder to hold your new
-#'   Nix project, and copy the `renv.lock` file only (not any of the other files
-#'   and folders generated by `{renv}`) and then call `renv2nix()` there. If
-#'   your project includes package with remote dependencies (for example, a
-#'   BioConductur package with a dependency on GitHub), `renv2nix()` will not
-#'   generate a valid `default.nix` file. The description of the issue and a
-#'   solution is given in the
-#'   `vignette("z-advanced-topic-handling-packages-with-remote-dependencies")`.
+#'   `{renv}` folder. We recommend that you start from an empty folder to hold
+#'   your new Nix project, and copy the `renv.lock` file only (not any of the
+#'   other files and folders generated by `{renv}`) and then call `renv2nix()`
+#'   there. For more details, see `vignette("f-renv2nix")`.
 #' @export
 #' @examples
 #' \dontrun{

vignettes/f-renv2nix.Rmd

@@ -18,18 +18,21 @@ knitr::opts_chunk$set(
 library(rix)
 ```
 
+*renv2nix() is early development stages and its arguments may change in the future*
+
 ## Introduction
 
-`{renv}` is very likely the most popular package to set up per project libraries
-of R packages. `{renv}` generates and manages so-called `renv.lock` files at the
-level of a project, and using these files it is thus possible to have different
-versions of the same packages on the same system, without any interference.
-However, `{renv}` doesn't snapshot R itself, so different projects with
-different libraries of packages will end up using the same version of R, which
-could lead to issues, especially if you're trying to restore an old project
-which relied on an old version of R. Also, in some cases, it might be impossible
-to restore a project due to incompatibilities at the level of the system-level
-dependencies, as these are not managed by `{renv}`.
+`{renv}` is very likely the most popular package for reproducibility in R.
+`{renv}` generates and manages so-called `renv.lock` files at the level of a
+project, and using these files it is thus possible to have different versions of
+the same packages on the same system, without any interference. However,
+`{renv}` doesn't snapshot R itself, so different projects with different
+libraries of packages will end up using the same version of R, which could lead
+to issues, especially if you're trying to restore an old project which relied on
+an old version of R. Also, in some cases, it might be impossible to restore a
+project due to incompatibilities at the level of the system-level dependencies,
+as these are not managed by `{renv}`. In our experience, the older the project,
+the less likely restoring it using `{renv}` will succeed.
 
 As explained extensively in this documentation already, Nix handles all the
 different pieces of the reproducibility puzzle: versions of R packages, versions
@@ -115,11 +118,12 @@ which you copy the `renv.lock` file.
 ### Mind the R version
 
 Many R users do not update R very often, so when they generate an `renv.lock`
-file, the `renv.lock` will list an old version of R, but quite recent packages.
-The way `{rix}` generates `default.nix` files is by looking at the version of R
-and then install packages that were current at that time. So if the `renv.lock`
-file lists an old version of R, the packages that will be included in the
-`default.nix` file will also be old. You could even end up in a situation where
-a package is not available because it only recently got released on CRAN. To
-avoid problems, use the `override_r_ver` argument of `renv2nix()` to provide a
-more recent version of R, that matches roughly when the packages were released.
+file, the `renv.lock` will list an old version of R, but potentially very recent
+packages. The way `{rix}` generates `default.nix` files is by looking at the
+version of R and then install packages that were current at that time. So if the
+`renv.lock` file lists an old version of R, the packages that will be included
+in the `default.nix` file will also be old. You could even end up in a situation
+where a package is not available because it only recently got released on CRAN.
+To avoid problems, use the `override_r_ver` argument of `renv2nix()` to provide
+a more recent version of R, that matches roughly when the packages were
+released.