r-lib
pak fails to install versioned packages from PPM
For example:
options(repos = c(CRAN = "https://packagemanager.posit.co/cran/__linux__/noble/latest"))
.libPaths(tempdir())
install.packages("pak", repos = sprintf("https://r-lib.github.io/p/pak/stable/%s/%s/%s", .Platform$pkgType, R.Version()$os, R.Version()$arch))
library(pak)
remotes <- c(
glue = "[email protected]",
pillar = "[email protected]",
vctrs = "[email protected]"
)
pak::pkg_install(remotes)
I see:
> pak::pkg_install(remotes)
Error:
! error in pak subprocess
Caused by error:
! Could not solve package dependencies:
* [email protected]: Can't install dependency glue
* glue: Conflicts with [email protected]
Type .Last.error to see the more details.
Note: I don't see any issues if I try to install packages from the default CRAN mirror. Does pak do some special dependency resolution when using PPM binary repositories, or anything like that?
This is with pak 0.8.0.
> sessionInfo()
R version 4.4.2 (2024-10-31)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 24.04.1 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.26.so; LAPACK version 3.12.0
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
time zone: America/Los_Angeles
tzcode source: system (glibc)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] pak_0.8.0
loaded via a namespace (and not attached):
[1] compiler_4.4.2 tools_4.4.2
See also: https://github.com/rstudio/renv/issues/2051#issuecomment-2529333954
I also face this issue, leading to my CI pipelines suddenly failing.
After bit of digging could trace it back to {pkgdepends} dependcy solver process - e.g. trying to resolve [email protected] from P3M fails for me
options(repos = c(CRAN = c("https://packagemanager.posit.co/cran/__linux__/jammy/latest")))
.libPaths(tempdir())
install.packages("pkgdepends")
library(pkgdepends)
pkg <- "[email protected]"
lib <- .libPaths()[1]
dependencies = NA
prop <- new_pkg_installation_proposal(pkg, config = list(library = lib,
dependencies = dependencies))
prop$resolve()
solution <- prop$get_resolution()
solution[,1:7]
prop$solve()
failure <- prop$get_solution()$failures
failure[,c("ref", "direct","version", "failure_type", "failure_message","failure_down")]
> library(pkgdepends)
> # this fails
> pkg <- "[email protected]"
> lib <- .libPaths()[1]
> dependencies <- NA
> prop <- new_pkg_installation_proposal(pkg, config = list(
+ library = lib,
+ dependencies = dependencies
+ ))
> prop$resolve()
✔ Loading metadata database ... done
> solution <- prop$get_resolution()
> solution[, 1:7]
ref type direct directpkg status package version
1 [email protected] standard TRUE TRUE OK glue 1.7.0
2 glue standard FALSE TRUE OK glue 1.8.0
> prop$solve()
> failure <- prop$get_solution()$failures
> failure[, c("ref", "direct", "version", "failure_type", "failure_message", "failure_down")]
ref direct version failure_type failure_message failure_down
1 [email protected] TRUE 1.7.0 binary-preferred NULL
2 glue FALSE 1.8.0 satisfy-direct Conflicts with [email protected]
Seems pkgdepends cannot decide between the two options, although it feels this should be straightforward
I also face this issue, leading to my CI pipelines suddenly failing.
Can you show a successful build and a failing one?
@gaborcsardi CI-wise its quite simple.. the failing pipelines (actually its a test step before building anything) fail because of pak throwing "dependency conflicts" during renv::restore() e.g.
* ragg: Can't install dependency textshaping (>= 0.3.0)
* textshaping: Conflicts with [email protected]
This did not happen a week ago, and checking on P3M textshaping got updated on Dec 6th
I think this traces back to what pkgdepends has in the "platform" field after resolution from P3M. E.g. above example with glue
# resolve using P3M
options(repos = "https://packagemanager.posit.co/cran/__linux__/jammy/latest")
prop_p3m <- new_pkg_installation_proposal(pkg, config = list(
library = lib,
dependencies = dependencies
))
prop_p3m$resolve()
solution_p3m <- prop_p3m$get_resolution()
solution_p3m[, c("ref", "type", "direct", "version", "needscompilation", "platform")]
ref type direct version needscompilation platform
1 [email protected] standard TRUE 1.7.0 TRUE x86_64-pc-linux-gnu
2 glue standard FALSE 1.8.0 FALSE x86_64-pc-linux-gnu-ubuntu-22.04
3 glue standard FALSE 1.8.0 TRUE source
Same table if std CRAN mirror is used:
# Resolve using "normal" CRAN mirror
options(repos = "https://stat.ethz.ch/CRAN/")
prop_cran <- new_pkg_installation_proposal(pkg, config = list(
library = lib,
dependencies = dependencies
))
prop_cran$resolve()
solution_cran <- prop_cran$get_resolution()
solution_cran[, c("ref", "type", "direct", "version", "needscompilation", "platform")]
ref type direct version needscompilation platform
1 [email protected] standard TRUE 1.7.0 TRUE x86_64-pc-linux-gnu
2 glue standard FALSE 1.8.0 TRUE source
3 glue standard FALSE 1.8.0 TRUE source
This subsequently leads to the [email protected] being thrown out by pkgdepends here in that block probably: https://github.com/r-lib/pkgdepends/blob/be0dd2a719425b79242917653129a3b664c9d071/R/solve.R#L638C1-L666C2
I am now confused if this is P3Ms, or pkgdepends issue
Update:
The platform field also comes from pgkdepends I realized. The pacakge description that is coming trough from P3M looks like this:
Browse[1]> dsc
Package: glue
Title: Interpreted String Literals
Version: 1.7.0
Authors@R (parsed):
* Jim Hester [aut] (<[https://orcid.org/0000-0002-2739-7082](vscode-file://vscode-app/c:/Users/lucas.habegger/AppData/Local/Programs/Positron/resources/app/out/vs/code/electron-sandbox/workbench/workbench.html#)>)
* Jennifer Bryan <[email protected]> [aut, cre] (<[https://orcid.org/0000-0002-6983-2759](vscode-file://vscode-app/c:/Users/lucas.habegger/AppData/Local/Programs/Positron/resources/app/out/vs/code/electron-sandbox/workbench/workbench.html#)>)
* Posit Software, PBC [cph, fnd]
Author: Jim Hester [aut]
(<[https://orcid.org/0000-0002-2739-7082](vscode-file://vscode-app/c:/Users/lucas.habegger/AppData/Local/Programs/Positron/resources/app/out/vs/code/electron-sandbox/workbench/workbench.html#)>), Jennifer Bryan [aut, cre]
(<[https://orcid.org/0000-0002-6983-2759](vscode-file://vscode-app/c:/Users/lucas.habegger/AppData/Local/Programs/Positron/resources/app/out/vs/code/electron-sandbox/workbench/workbench.html#)>), Posit Software, PBC [cph,
fnd]
Maintainer: Jennifer Bryan <[email protected]>
Description: An implementation of interpreted string literals,
inspired by Python's Literal String Interpolation
<[https://www.python.org/dev/peps/pep-0498/](vscode-file://vscode-app/c:/Users/lucas.habegger/AppData/Local/Programs/Positron/resources/app/out/vs/code/electron-sandbox/workbench/workbench.html#)> and Docstrings
<[https://www.python.org/dev/peps/pep-0257/](vscode-file://vscode-app/c:/Users/lucas.habegger/AppData/Local/Programs/Positron/resources/app/out/vs/code/electron-sandbox/workbench/workbench.html#)> and Julia's Triple-Quoted
String Literals
<[https://docs.julialang.org/en/v1.3/manual/strings/#Triple-Quoted-String-Literals-1](vscode-file://vscode-app/c:/Users/lucas.habegger/AppData/Local/Programs/Positron/resources/app/out/vs/code/electron-sandbox/workbench/workbench.html#)>.
License: MIT + file LICENSE
URL: [https://glue.tidyverse.org/,](vscode-file://vscode-app/c:/Users/lucas.habegger/AppData/Local/Programs/Positron/resources/app/out/vs/code/electron-sandbox/workbench/workbench.html#)
[https://github.com/tidyverse/glue](vscode-file://vscode-app/c:/Users/lucas.habegger/AppData/Local/Programs/Positron/resources/app/out/vs/code/electron-sandbox/workbench/workbench.html#)
BugReports: [https://github.com/tidyverse/glue/issues](vscode-file://vscode-app/c:/Users/lucas.habegger/AppData/Local/Programs/Positron/resources/app/out/vs/code/electron-sandbox/workbench/workbench.html#)
Depends:
R (>= 3.6)
Imports:
methods
Suggests:
crayon,
DBI (>= 1.2.0),
dplyr,
knitr,
magrittr,
rlang,
rmarkdown,
RSQLite,
testthat (>= 3.2.0),
vctrs (>= 0.3.0),
waldo (>= 0.3.0),
withr
VignetteBuilder:
knitr
Built: R 4.4.0; x86_64-pc-linux-gnu; 2024-04-25 19:45:13 UTC; unix
ByteCompile: true
Config/Needs/website: bench, forcats, ggbeeswarm, ggplot2,
R.utils, rprintf, tidyr, tidyverse/tidytemplate
Config/testthat/edition: 3
Date/Publication: 2024-01-09 23:13:08 UTC
Encoding: UTF-8
NeedsCompilation: yes
Packaged: 2024-01-08 16:10:57 UTC; jenny
Repository: RSPM
RoxygenNote: 7.2.3.9000
so pkgdepends parses the Built: field and fills a platform, even tough this is a source pkg. Could this be because it was once there with a binary, then archived and the binary removed?
@gaborcsardi Sorry, can you help here? I originally opened the corresponding renv issue. https://github.com/rstudio/renv/issues/2051#issuecomment-2529333954
It's possible to restore a lock file as long as pak is not activated.
But since kevin could should that this can be reproduced with pak only (so without renv) this is probably a pak issue? I consider this a bug since this works without pak.
Kevin showed a minimal reproducible example int he first post.
I also created a github repo with a dockerfile https://github.com/mihem/docker_renv_pak_debug to make it reproducible across machines. Here's the error https://github.com/mihem/docker_renv_pak_debug/actions/runs/12220756689/job/34088962358.
Thanks!
@gaborcsardi @kevinushey ping. I know you have a lot of stuff to do but I cannot use pak with renv and without pak renv is really slow for larger projects.
@gaborcsardi @kevinushey ping. I know you have a lot of stuff to do but I cannot use pak with renv and without pak renv is really slow for larger projects.
@mihem perhaps this will change with R 4.5 release and parallel package downloads and installations https://www.jumpingrivers.com/blog/whats-new-r45/
Agree, also read this with excitement, however if i understood @kevinushey post correctly, this is more complicated than just updating to R 4.5 https://github.com/rstudio/renv/issues/2099#issuecomment-2744660360
Isn't this just because to use pak, renv needs to install it, and it seems to install its Suggests which include glue but all that is done without respecting the renv.lock file. Once that's done, and packages are restored, there are version clashes between what was installed for pak features, and what is pinned in renv.lock.
This issue specifically is independent of renv, though -- it can be reproduced using pak only, without any renv integration.
@kevinushey Oops sorry :D I indeed come from renv threads that lead here.
So, is the problem rooted in pak coming with its own version of glue, where it conflates its own deps constraints with what it is instructed to install (R "libraries" limitation?) or is it something else?