renv::restore with pak errors when using a custom git package

[LeeMendelowitz]

When using pak with renv 1.0.7, I'm getting in error when trying to renv::restore() using a custom git repo. I'm able to renv::install the package with pak, it's just the restore that fails with an error.

Here's an example of how I installed from a custom git repo (where I replaced my actual url with a dummy url). The install with pak worked fine, and update the renv.lock:

renv::install('git::https://gitlab.example.net/path/example.git')

# Or could use a local repo:
# renv::install("~/projects/example")

renv::snapshot()

The renv.lock has:

    "example": {
      "Package": "example",
      "Version": "1.0.0",
      "Source": "git",
      "RemoteType": "git",
      "RemoteUrl": "https://gitlab.example.net/path/example.git",
      "RemotePkgRef": "git::https://gitlab.example.net/path/example.git",
      "RemoteRef": "HEAD",
      "RemoteSha": "xxx",
      "Requirements": [
        "DBI",
        "R",
        "tibble"
      ],
      "Hash": "xxx"
    },

To test the renv::restore(), I rm -rf renv/library. But a call to renv::restore() with this lock file will fail with:

# Installing packages --------------------------------------------------------
- Installing pak ...                            OK [linked from cache]
Successfully installed 1 package in 13 milliseconds.
✔ Loading metadata database ... done
Error:
! error in pak subprocess
Caused by error:
! Could not solve package dependencies:
* R6@2.5.1: dependency conflict
* RColorBrewer@1.1-3: dependency conflict
* RMySQL@0.10.28: dependency conflict
* DBI@1.2.3: dependency conflict
* callr@3.7.6: dependency conflict
* Matrix@1.6-5: dependency conflict
* MASS@7.3-60.0.1: dependency conflict
* crayon@1.5.3: dependency conflict
* desc@1.4.3: dependency conflict
* curl@5.2.1: dependency conflict
* dplyr@1.1.4: dependency conflict
* fs@1.6.4: dependency conflict
* gtable@0.3.5: dependency conflict
* labeling@0.4.3: dependency conflict
* lambda.r@1.2.4: dependency conflict
* lubridate@1.9.3: dependency conflict
* magrittr@2.0.3: dependency conflict
* openssl@2.2.1: dependency conflict
* pillar@1.9.0: dependency conflict
* pkgbuild@1.4.4: dependency conflict
* pkgconfig@2.0.3: dependency conflict
* pkgload@1.4.0: dependency conflict
* processx@3.8.4: dependency conflict
* ps@1.7.7: dependency conflict
* vctrs@0.6.5: dependency conflict
* viridisLite@0.4.2: dependency conflict
* withr@3.0.1: dependency conflict
* xml2@1.3.6: dependency conflict
* Rcpp@1.0.13: dependency conflict
* arrow@17.0.0.1: dependency conflict
* duckdb@1.0.0-2: dependency conflict
* fansi@1.0.6: dependency conflict
* farver@2.1.2: dependency conflict
* formatR@1.14: dependency conflict
* futile.logger@1.4.3: dependency conflict
* futile.options@1.0.1: dependency conflict
* scales@1.3.0: dependency conflict
* selectr@0.4-2: dependency conflict
* stringi@1.8.4: dependency conflict
* stringr@1.5.1: dependency conflict
* sys@3.4.2: dependency conflict
* tibble@3.2.1: dependency conflict
* bit@4.0.5: dependency conflict
* bit64@4.0.5: dependency conflict
* cli@3.6.3: dependency conflict
* colorspace@2.1-1: dependency conflict
* generics@0.1.3: dependency conflict
* ggplot2@3.5.1: dependency conflict
* purrr@1.0.2: dependency conflict
* rlang@1.1.4: dependency conflict
* rprojroot@2.0.4: dependency conflict
* rvest@1.0.4: dependency conflict
* tidyr@1.3.1: dependency conflict
* tidyselect@1.2.1: dependency conflict
* mongolite@2.8.0: dependency conflict
* munsell@0.5.1: dependency conflict
* example@1.0.0: Can't find package called example@1.0.0.
* nlme@3.1-166: dependency conflict
* timechange@0.3.0: dependency conflict
* utf8@1.2.4: dependency conflict
* lattice@0.22-6: dependency conflict
* lifecycle@1.0.4: dependency conflict
* mgcv@1.9-1: dependency conflict
* mime@0.12: dependency conflict
* askpass@1.2.0: dependency conflict
* assertthat@0.2.1: dependency conflict
* glue@1.7.0: dependency conflict
* httr@1.4.7: dependency conflict
* isoband@0.2.7: dependency conflict
* jsonlite@1.8.8: dependency conflict
Type .Last.error to see the more details.
Traceback (most recent calls last):
6: renv::restore()
5: renv_pak_restore(lockfile = lockfile, packages = packages, exclude = exclude,
       project = project)
4: pak$pkg_install(remotes)
3: remote(function(...) get("pkg_install_make_plan", asNamespace("pak"))(...),
       list(pkg = pkg, lib = lib, upgrade = upgrade, ask = ask,
           start = start, dependencies = dependencies, loaded = loaded_packages(lib)))
2: err$throw(res$error)
1: base::stop(cond)

The same error occurs if I try installing a local git repo (i.e. renv::install("~/projects/example").

SessionInfo

> sessionInfo()
R version 4.3.2 (2023-10-31)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Monterey 12.7.1

Matrix products: default
BLAS:   /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.11.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Chicago
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base

loaded via a namespace (and not attached):
[1] compiler_4.3.2 tools_4.3.2    renv_1.0.7     pak_0.8.0

[kevinushey]

This sounds somewhat similar to

renv/NEWS.md

Lines 68 to 70 in fcfe748

	* Fixed an issue with `renv`'s `pak` integration where `renv` could install the
	wrong version of a GitHub package during restore if
	`options(renv.config.pak.enabled = TRUE)` was set. (#1883)

-- do you see the same issue in the development version of renv?

[LeeMendelowitz]

@kevinushey

Yes, this is still an issue in the latest development version of renv. When I try to restore an renv.lock that was generated without pak enabled that uses the custom git repo, I get the error above.

[kevinushey]

Thanks -- do you by any chance have a standalone reproducible example I could use for testing? (Can the issue be reproduced readily using any publicly-available R packages on GitHub, but using git references to access those?)

[LeeMendelowitz]

Yup I was able to get a reproducible example using the gt package. Interestingly, calling renv::install("git::git@github.com:rstudio/gt.git") with pak enabled errors out, which might be the heart of the issue. The restore of a lockfile with pak enabled also errors out.

export RENV_CONFIG_CACHE_ENABLED=FALSE


# Step A: Install gt package from GitHub over SSH
# This works fine.
R --no-save <<EOF
renv::init()
renv::install("git::git@github.com:rstudio/gt.git")
renv::snapshot(type="all")
EOF


# Step B: Try restoring with pak enabled. This fails.
RENV_CONFIG_PAK_ENABLED=TRUE R --no-save <<EOF
renv::restore()
EOF


# Step C: Repeat without pak enabled. This works fine.
# It says "The library is already synchronized with the lockfile."
RENV_CONFIG_PAK_ENABLED=FALSE R --no-save <<EOF
renv::restore()
EOF


# Step D: Calling renv::install() with pak enabled also fails.
RENV_CONFIG_PAK_ENABLED=TRUE R --no-save <<EOF
renv::install("git::git@github.com:rstudio/gt.git")
EOF

[LeeMendelowitz]

@kevinushey Sorry forgot to mention you in last comment - I added a reproducible example above.