"path must exist" with pak::lockfile_install() on archived/old packages
#425
Comments
mcanouil
changed the title
path must exist" when pak::lockfile_install(update = TRUE)path must exist" with pak::lockfile_install() on archived/old packages
|
From the manual:
Unfortunately you cannot reliably use pak's lock files like this currently. |
|
oh, I missed that part.🤦♂️
|
|
OTOH, this specific case should work fine, and it is indeed a bug in pak/pkgdepends: the alternative URL is wrong, instead of it should be |
Waiting for r-lib/pak#425
|
Yes, I think we could document the cases when lock files are reliable. E.g. if you only use CRAN source packages, then they should work fine. An MRAN snapshot should be also fine, as that never changes. It is possible that RSPM snapshots also work, and packages from Bioc could be fines as well (possibly even their binaries), but I would need to double check that. |
|
Thanks, I think the safest would be to set MRAN as default repository in the Dockerfile and document it in the website for my current use case (when most of the development will be over). |
|
This is now fixed in dev pkgcache and will be fixed in the the next dev pak builds. I'll comment here when they are available. |
|
This should be available now, except on arm64 platforms. |
|
Thanks, for now I simply manually updated the archive URLs. |
Waiting for r-lib/pak#425
# pkgcache 2.0.3 * The `built` and `sysreqs` columns of the metadata case are always character vectors now, and not logicals, as it used to be in some edges cases in the past. * The `deps` column of the metadata cache is not a tibble any more, but a data frame with a `tbl` class, as it should be. * `cran_archive_*()` functions now only download the metadata if it is newer than what you have currently. * `cran_archive_cleanup()` now does not ignore the `force` argument. * The `sources` column in the metadata cache now has the correct URL for packages in the CRAN archive (r-lib/pak#425). # pkgcache 2.0.2 * pkgcache error messages are better now. * pkgcache now does not compress the metadata cache files, which makes loading the metadata cache faster.
Hi,
I have been facing an issue when restoring a lock file with
pakwhen the version is no longer the latest available on CRAN.For example, a lock file generated with
pakforcurl4.3.2{ "lockfile_version": 1, "os": "Debian GNU/Linux 11 (bullseye)", "r_version": "R version 4.2.0 (2022-04-22)", "platform": "x86_64-pc-linux-gnu", "packages": [ { "ref": "curl", "package": "curl", "version": "4.3.2", "type": "standard", "direct": false, "binary": false, "dependencies": [], "vignettes": false, "metadata": { "RemotePkgRef": "curl", "RemoteType": "standard", "RemoteRef": "curl", "RemoteRepos": "https://cloud.r-project.org", "RemotePkgPlatform": "source", "RemoteSha": "4.3.2" }, "sources": ["https://cloud.r-project.org/src/contrib/curl_4.3.2.tar.gz", "https://cloud.r-project.org/src/contrib/Archive/curl_4.3.2.tar.gz"], "target": "src/contrib/curl_4.3.2.tar.gz", "platform": "source", "rversion": "*", "directpkg": false, "license": "MIT + file LICENSE", "dep_types": ["Depends", "Imports", "LinkingTo"], "params": [], "install_args": "", "needscompilation": true, "sha256": "90b1facb4be8b6315bb3d272ba2dd90b88973f6ea1ab7f439550230f8500a568", "filesize": 793345, "repotype": "cran" } ] }A Dockerfile (based on Debian 11) build using
docker buildx build --platform "linux/amd64" --file Dockerfile .The produced log
Right now, the latest version of
curlis 4.3.3 on CRAN.If the lock file is pointing to the CRAN version, it is restored properly.
curl4.3.3 lock file{ "lockfile_version": 1, "os": "Debian GNU/Linux 11 (bullseye)", "r_version": "R version 4.2.0 (2022-04-22)", "platform": "x86_64-pc-linux-gnu", "packages": [ { "ref": "curl", "package": "curl", "version": "4.3.3", "type": "standard", "direct": true, "binary": false, "dependencies": [], "vignettes": false, "needscompilation": true, "metadata": { "RemoteType": "standard", "RemotePkgRef": "curl", "RemoteRef": "curl", "RemoteRepos": "https://cloud.r-project.org", "RemotePkgPlatform": "source", "RemoteSha": "4.3.3" }, "sources": ["https://cloud.r-project.org/src/contrib/curl_4.3.3.tar.gz", "https://cloud.r-project.org/src/contrib/Archive/curl_4.3.3.tar.gz"], "target": "src/contrib/curl_4.3.3.tar.gz", "platform": "source", "rversion": "*", "directpkg": true, "license": "MIT + file LICENSE", "sha256": "3567b6acad40dad68acfe07511c853824839d451a50219a96dd6d125ed617c9e", "filesize": 670416, "dep_types": ["Depends", "Imports", "LinkingTo", "Suggests"], "params": [], "install_args": "", "repotype": "cran" } ] }Docker build log from the same Dockerfile as above
The original issue was encountered with https://github.com/mcanouil/eggla/tree/main/inst/setup using the following GitHub Action workflow https://github.com/mcanouil/eggla/blob/main/.github/workflows/build-docker.yml.
The text was updated successfully, but these errors were encountered: