Binary packages removed once new package version released on PPM?

[lorenzwalthert]

Not sure this is the right place to ask but it seems to me that whenever a new package version is released, the old binaries are no longer available on PPM. Is that correct? Do you plan to provide access to archived binaries as well in the future? A use case is

• I clone a project managed with renv. The project has a system dependency (like {stringr} -> {stringi}) that is not up to date in the renv.lock.
• I can't install the binary from PPM since it has been removed. I need to either renv::update() or install build dependencies on my system or use another repository.

My use case is my {precommit} package, where hundreds of people clone my repo every week and then run into these issues, as my renv.lock is only updated ~ every two weeks. Example issue here.

I know this would blow up storage requirements but support for one archived version would already be much appreciated, I can understand keeping (or even building) the whole history of releases is close to infeasible. PPM has made live of pre-commit R users a lot easier, thanks for providing this service for free.

[greg]

Hi @lorenzwalthert, this is the right place to ask. So technically, PPM never removes old binary packages after new versions have released, and storage of them isn't an issue. These old binaries can still be accessed from PPM.

However, the URLs for these old binaries do change over time, depending on several factors like whether you're using the /latest repository URL vs. a frozen snapshot, or whether you're on macOS/Windows vs. Linux.

For macOS and Windows:

The main issue is just that R (and CRAN) doesn't support installing archived binary packages natively. Source packages have an /src/contrib/Archive section on CRAN with archived sources for each package, e.g. Index of /src/contrib/Archive/xfun. install.packages() doesn't support installing from this archive, but user packages like renv and remotes/devtools may. However, there's no equivalent section on CRAN for archived binaries. So while PPM does have all the old binaries, we don't have any CRAN-standard place to serve them from.

For Linux:

Unlike macOS/Windows, PPM does provide archived binaries for Linux because Linux binary repos are non-standard. R doesn't support installing binary packages on Linux in the first place, so PPM's Linux binaries are disguised as source packages and do have a /src/contrib/Archive section. We put archived Linux binaries there so renv/devtools/etc. can find them easily.

On macOS/Windows, it is still possible to install old binary packages if you use the frozen snapshot URLs. You can pick a date in the past where the old package version was current and install the binary from the old snapshot. If you have an renv lockfile with a frozen repo snapshot URL, then that lockfile should always be restorable with the same packages in the future. For example, the old xfun 0.40 Windows binary for R 4.3 can still be found at https://packagemanager.posit.co/cran/2023-10-31/bin/windows/contrib/4.3/xfun_0.40.zip

If you use the /latest repository URL though, like https://packagemanager.posit.co/cran/latest, then the latest available packages will change over time, and macOS/Windows binaries will be unavailable as soon as the next package version is released.

I'm not sure if it makes sense to use frozen snapshot URLs in precommit's case, but that's a route if possible. You could pin the CRAN repo URL to the current day every time you update renv.lock and users on all OSs would get predictable results.

Otherwise, this issue has come up in the past, and we've talked about adding non-standard support for archived Windows/macOS binaries in PPM that renv and others could integrate with. It's not on the short-term roadmap, but provides enough benefit that I could see it happening some day.

[lorenzwalthert]

Thanks for the fast and detailed response. Very helpful. I agree in this case that we can opt for fixed snapshots then to mitigate the problem.