pak fails to install versioned packages from PPM

[kevinushey]

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:
* vctrs@0.6.5: 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: rstudio/renv#2051 (comment)

[kevinushey]

Also note: [email protected] is one version behind the current release, glue 1.8.0.

[lhabegger]

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

[gaborcsardi]

I also face this issue, leading to my CI pipelines suddenly failing.

Can you show a successful build and a failing one?

[lhabegger]

@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

[lhabegger]

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?

[mihem]

@gaborcsardi Sorry, can you help here? I originally opened the corresponding renv issue. rstudio/renv#2051 (comment)
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!

[mihem]

@gaborcsardi Sorry, any news on this? Any further information I can provide?