make renv sysreqs feature usable with RedHat based linux distros

[michaelmayer2]

With the latest release of renv I get

> sysreqs(packages=x$Package,distro="centos")
The requisite system packages can be installed with:
- sudo <install> -y cmake
- sudo <install> -y gdal
- sudo <install> -y gdal-devel
- sudo <install> -y geos-devel
- sudo <install> -y libcurl-devel
- sudo <install> -y libicu-devel
- sudo <install> -y libxml2-devel
- sudo <install> -y make
- sudo <install> -y openssl-devel
- sudo <install> -y pandoc
- sudo <install> -y pandoc-citeproc
- sudo <install> -y proj-devel
- sudo <install> -y proj-epsg
- sudo <install> -y sqlite-devel
- sudo <install> -y udunits2-devel
- sudo <install> -y v8-devel
- sudo <install> -y xz

Depending on the RedHat version it should use either yum or dnf instead of <install> - Nit-pickingly one even could consider clubbing all the lines together in one yum/dnf call like yum install -y cmake gdal gdal-devel....

On a related note: sysreqs at the moment does not consider any pre_install or post_install scripts (cf. https://github.com/rstudio/r-system-requirements/blob/fb86c68dcfd51a80034dcad925bdf7660cfc2bd2/rules/libwebp.json#L57-L61)

[kevinushey]

Nit-pickingly one even could consider clubbing all the lines together

FWIW you can use sysreqs(collapse = TRUE) for that.

[kevinushey]

This should be better handled with renv 1.1.3 -- please let me know if you encounter any other issues.

[michaelmayer2]

This looks much better now indeed: Some minor issues still remain I am afraid:

Issue 1:

> renv::sysreqs(packages=as.data.frame(installed.packages())$Package,distro="rockylinux")
Error in parts[[2L]] : subscript out of bounds

which contradicts the renv::sysreqs() documentation that a version suffix can be added.

When I add a version suffix however, I get

Issue 2:

> renv::sysreqs(packages=as.data.frame(installed.packages())$Package,distro="rockylinux:12")
System pre-requisites can be installed with:
- dnf install -y epel-release

The requisite system packages can be installed with:
- sudo <install> -y zeromq-devel

where

• pre-requisites are listing dnf correctly as a command but missing the sudo
• requisites still produce <install>
• version 12 of RockyLinux does not even exist but result with rockylinux:9 and redhat:9 is the same.

[kevinushey]

Thanks; the first one was a bug and is now fixed in the development version.

For the second one, I think the behavior is correct. r-system-requirements has:

      {
        "packages": [
          "zeromq-devel"
        ],
        "pre_install": [
          {
            "command": "dnf install -y epel-release"
          }
        ],
        "constraints": [
          {
            "os": "linux",
            "distribution": "rockylinux"
          }
        ]
      },

and so it lists zeromq-devel as the appropriate package dependency without any declared version constraint.

I can add dnf as the appropriate installer command for rockylinux here. Do you think renv should prepend sudo to the pre_install command?

[michaelmayer2]

Thanks for fixing this so swiftly ! I am just a bit intrigued by this new feature and cannot stop testing it...

As far as "to sudo or not to sudo" is concerned - I am fairly impartial here - it just needs to be consistent - if the prerequisites use sudo and the requisites do not, then that will cause confusion at the least.

If packages in r-system-requirements matches zeromq-devel, then for this OS the requisite command should be precisely dnf install -y zeromq-devel and not sudo <install> -y zeromq-devel.

The versioning remark was only referring to the linux distribution where it seems that arbitrary versions of a given distribution can be used and renv::sysreqs() will still deliver an answer.

[kevinushey]

I guess it depends on what the final destination for the output is -- is this something you want to run in a Terminal on your Linux machine, or is this something you want to throw in a Dockerfile? For the first scenario, you probably want sudo; for the second, you don't need it.

[michaelmayer2]

I guess it depends on what the final destination for the output is -- is this something you want to run in a Terminal on your Linux machine, or is this something you want to throw in a Dockerfile? For the first scenario, you probably want sudo; for the second, you don't need it.

Indeed - but arguably someone that wants to run the commands that will lead to the installation of additional software should know when to use sudo and when not.

As mentioned, all I really would like to see is consistency - I don't care whether you go with sudo or without sudo as output.

Not sure if it would be too much overkill to detect if the renv::sysreqs() is run as normal user (uid>0) and then add sudo while if the same is run under a user with effective uid=0 (i.e. root) to discard the sudo ?

[kevinushey]

Can you file a separate issue for that, so I don't forget about this?

[michaelmayer2]

Absolutely, here it is #2124

Thanks for all the good work on renv !