Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

`lockfile_install()` reinstalls source packages every time when CRAN is cran.r-universe.dev

Open
  • Is something wrong?
#486 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
70/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
r
Domain
tooling

Research direction

Start with installedok_remote_cran(), installedok_remote_standard(), add_metadata(), and pkgplan_update(), then run the minimal reproduction using cran.r-universe.dev and pak::lockfile_install(). Compare the installed metadata with the lockfile entry. Done means a second installation recognizes the source package as kept instead of rebuilding it.

Written by the indexing model from the issue text.

Description

I noticed this on cmdstanr's windows-11-arm GitHub Actions job, where setup-r-dependencies restores a 93 MB library from the cache and then pak::lockfile_install() rebuilds the whole thing from source anyway ("Will install 91 packages", "added 90, dld 90", about 26 minutes). The same workflow on windows-latest says "kept 86, added 3" and is done in 20 seconds. See https://github.com/stan-dev/cmdstanr/actions/runs/37052454400/job/110988918897 setup-r-dependencies step.

I did some digging (Claude assisted) and I think this is because the R build that setup-r installs on Windows ARM sets CRAN to https://cran.r-universe.dev. With pak 0.11.1 every entry in our lockfile is "platform": "source", "repotype": "cran", and installedok_remote_cran() requires

    identical(installed[["repository"]], "CRAN")

But source tarballs from r-universe use Repository: https://cran.r-universe.dev in DESCRIPTION, and add_metadata() writes the Remote* fields but doesn't touch Repository, so nothing pak installed from r-universe can pass the check and pkgplan_update() just reinstalls everything on every run.

I asked Claude to come up with this minimal reproducible example (I see the same thing with pak 0.9.2 and 0.11.1.9000):

    Sys.setenv(PKG_PLATFORMS = "source")
    options(repos = c(CRAN = "https://cran.r-universe.dev"))
    lib <- tempfile(); dir.create(lib)
    pak::lockfile_create("abind", lockfile = "pkg.lock", lib = NULL)
    pak::lockfile_install("pkg.lock", lib = lib)  # added 1
    pak::lockfile_install("pkg.lock", lib = lib)  # added 1 again
    packageDescription("abind", lib.loc = lib)$Repository
    #> "https://cran.r-universe.dev"

If repos is set to c(CRAN = "https://cloud.r-project.org") the second call says "kept 1" and Repository is "CRAN".

Would a solution be for the source branch to also accept a package whose RemoteRepos matches the lockfile entry, the way installedok_remote_standard() does for source packages from other repos? pak writes RemoteRepos at install time, so anything pak installed would pass.

Dominant language
C
Stars
135
Forks
47
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from r-lib/pkgdepends

All issues in r-lib/pkgdepends

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.