Open maximsmol opened 1 year ago
Note: filed the issue on this project because inspecting an installation plan directly shows that the libudunits2-dev
is not in the solution. The resolution is also different though it always shows the library (but apparently it needs to be included twice in different formats to actually work?)
Yes, good catch. This is because CRAN metadata does not contain the SystemRequirements
field, and we need to extract it (regularly) and download it from another source. But we only use this other source for repos that are called CRAN
or RSPM
, to avoid using it for the wrong package from another CRAN-like repo.
E.g. this is the metadata:
> pkgs <- pak::meta_list()
> pkgs[pkgs$package == "units", c("package", "sources", "sysreqs")]
package
18965 units
38358 units
sources
18965 https://packagemanager.posit.co/cran/__linux__/jammy/latest/src/contrib/units_0.8-2.tar.gz
38358 https://cloud.r-project.org/src/contrib/units_0.8-2.tar.gz, https://cloud.r-project.org/src/contrib/Archive/units/units_0.8-2.tar.gz
sysreqs
18965 <NA>
38358 udunits-2
For the binary
repo we have sysreqs = NA
, for CRAN we have the sysreqs information. But then we select the binary one for installation, because binary packages are preferred, and thus no system packages are installed.
When you call it again, we use SystemRequirements
from the installed package, so it works correctly.
I am not yet sure how, but we should definitely improve this. Possibly we could have a more robust detection for RSPM, instead of just using the repo name.
Thanks for the explanation!
I think the current behavior is fine if it's prominently documented somewhere in pak
. I spent quite a bit of time trying to figure out why this wasn't working but there is nothing stopping me from just renaming the repo.
I think it is OK to use SystemRequiements
whenever the package name and version matches. It is unlikely that there would be a completely different package with the same name and version number in another repository. In any case, this is something to fix in pkgcache, here-ish: https://github.com/r-lib/pkgcache/blob/7f3b3af5f79fffe64dd9910da1acfd7e6bec8faa/R/metadata-cache.R#L440-L443
The
repos
option can have thehttps://packagemanager.posit.co
entry under any key, but system requirements only resolve correctly when the key is exactlyRSPM
Reproduction Steps
docker run -it rhub/rig /bin/bash -l -c 'R' # get an R session in the login environment
options(repos = c(binary = "https://packagemanager.posit.co/cran/__linux__/jammy/latest", CRAN = "https://cloud.r-project.org")) # rename the 'RSPM' repo to 'binary'
pak::pkg_install("units")
library(units)
gives an errorOutput with
RSPM
Output with
binary