renv looks for specific library version instead of general one

[skwde]

The problem is also visible here #1834 but in a different context.

Sticking with the sodium and libsodium mentioned in the liked issue.
On https://cran.r-project.org/web/packages/sodium/index.html the system requirements mention libsodium (>= 1.0.3) but I get the error

libsodium.so.23: cannot open shared object file: No such file or directory

when libsodium@1.0.19 is installed. Checking which libsodium version still has libsodium.so.23 the web tells me libsodium@1.0.18. When I use this version the installation goes through.

I experience the same problem when e.g. installing sf which requires GDAL / PROJ. Detailed information are in the sf issue r-spatial/sf#2360. Picking only the PROJ issue, they mentioned on https://cran.r-project.org/web/packages/sf/index.html that PROJ (>= 4.8.0) is required, but when installing with PROJ 4.9.2 present I get

libproj.so.15: cannot open shared object file: No such file or directory

because this version comes with

libproj.a
libproj.so
libproj.so.9
libproj.so.9.1.0

updating to PROJ 8.2.1 I get the same error because this version comes with

libproj.a
libproj.so
libproj.so.22
libproj.so.22.2.1

Only when searching online which PROJ version ships libproj.so.15 and using that version the error goes away.
So I am wondering how I should know beforehand which system dependency versions are actually required and why renv picks the very specific version lib instead of the .so file (without the version), because obviously the package authors didn't specify such a narrow version requirement.

[kevinushey]

Are you making use of Posit package manager here? I wonder if the issue is related to the binaries served by PPM rather than an issue in renv.

So I am wondering how I should know beforehand which system dependency versions are actually required and why renv picks the very specific version lib instead of the .so file (without the version), because obviously the package authors didn't specify such a narrow version requirement.

To be clear, renv is not involved in this part of the process. My best guess is that binaries from PPM are being used, and those binaries are linked to different versions of these requisite system libraries than is expected.

[skwde]

I am not sure how to check if the PPM was used.

I addition is it possible to still see if binaries where used or if the packages where build from source?

At least I had the impression that the pacakges where installed form source.
Occasionally I used rebuild=TRUE but cannot say for if the mentioned issue also occurred here (I dealt with a whole bunch of issues, so I don't remember exactly)

[skwde]

Are you making use of Posit package manager here? I wonder if the issue is related to the binaries served by PPM rather than an issue in renv.

So I am wondering how I should know beforehand which system dependency versions are actually required and why renv picks the very specific version lib instead of the .so file (without the version), because obviously the package authors didn't specify such a narrow version requirement.

To be clear, renv is not involved in this part of the process. My best guess is that binaries from PPM are being used, and those binaries are linked to different versions of these requisite system libraries than is expected.

It seems everybody is just pushing the problem away.

See related sf reply: r-spatial/lwgeom#90 (comment)

[kevinushey]

Sorry -- I would be able to provide better help if I could reproduce the problem locally, but thus far I have not been able to.

What is the output of renv::install("sodium", verbose = TRUE) for you?

[skwde]

No problem, I actually already solved the problem simply by installing the specific system dependencies providing the specific .so.* asked for. I just wanted to make both sides aware of the problem.

In any case, when I just tried reproduce the error I got earlier with an older version of sodium I realized that for the most recent sodium version the binary was used (thanks to the verbose=TRUE you mentioned) while for the older package it built from source.
Apparently the behavior of type (and its default) is also mentioned in the docs (https://rstudio.github.io/renv/reference/install.html).

When using type="source" to install the latest sodium it looks like it is picking up the correct libsodium provided via env variables.

At least from what I can tell now, it really looks like as if the problem was simply due to type defaulting to binary when installing sodium. (Something you hinted already above).