Facilitating long-term reproducibility of dependent code

[fkohrt]

As a researcher studying reproducibility, I had mixed feelings when I read that r-universe does not archive anything. I feel like the R community (as every other tech community) loves to adopt fancy new technology, and r-universe most certainly appears as such compared to CRAN. Future package developers will want to adopt this new exciting path, probably at the expense of making their packages available at CRAN. I fear that in a decade from now, we might experience that some of the packages distributed via r-universe now are not available anymore (due to the Git remote becoming unavailable, for whatever reason).

There are some things one could do if r-universe archiving packages (sources or binaries) is unwanted or infeasible (though I read that regular snapshots are not off the table, see #91). For example, the importance of enabling long-term archivability could be communicated to package developers who expect their contributions be used in scientific pipelines. Also, I could imagine a fruitful collaboration with the Software Heritage Code Archive.

What are your thoughts on r-universe's role in code reproducibility? Given that rOpenSci explicitly has reproducibility as part of their mission, I wonder how r-universe can support that.

[jeroen]

What are your thoughts on r-universe's role in code reproducibility? Given that rOpenSci explicitly has reproducibility as part of their mission, I wonder how r-universe can support that.

We have an API that makes to download snapshots of your entire package repository, such that you can easily backup/mirror them at any point as you like. For example if you go to https://ropensci.r-universe.dev/api at the bottom of the page you can get snapshots for the ropensci universe. The snapshot is a full cranlike package repository, so you can simply host that on any http server or you can make R install locally from your snapshot locally.

The idea is that this will give you control over your reproducibility. It is too expensive for us to archive all the things that have ever been built on r-universe. But with this API you can easily arrange this yourself. For example if you want to create a time-machine like system, you can downloads a snashot of your repo every day or week and host that on a place of your liking.

[fkohrt]

Ah, I see, the snapshots are not created by r-universe, but can be stored by anybody.

I understand that r-universe cannot archive packages, but maybe make it very easy for developers to have their packages archived by Software Heritage? For example, every time the build process runs, the Git remote for that package could be stored in their code archive. This could be an opt-out option in case developers don't want their software archived.

[jeroen]

How would we do that? We already expose the RemoteSha for each package via the api for example: https://jeroen.r-universe.dev/api/packages/jsonlite. Would we need something more?

[fkohrt]

My knowledge about Software Heritage is limited, so I have brought the discussion to their swh-devel mailing list. There, the question was raised whether the binary packages built by r-universe contain anything that cannot be rebuilt from source later?

Also, I'm wondering whether the following is a correct depiction of how r-universe works:

There are two ways of entry for a package on r-universe: Either by creating a repo called <name>.r-universe.dev on GitHub, or by having it on CRAN.

For the former, one has to differentiate between (a) the definition of a “personal universe” and (b) the individual packages within that universe. For (a) only GitHub is supported at the time. On GitHub, one creates a repo called <name>.r-universe.dev, creates a file packages.json, and installs the GitHub app. For (b), the individual packages listed in packages.json may be stored at any public git URL.

For the latter, r-universe considers all CRAN packages (that have not been removed) and decides on a per-package basis from which source the package is being rebuilt: If the package DESCRIPTION file contains a known Git forge (GitHub, GitLab, Bitbucket, and possibly a few others), it uses that. Otherwise it uses the CRAN source files to rebuild it – in that case, no RemoteSha is exposed, but a _commit.id for the corresponding repo at github.com/cran.

Does that sound about right?

For example, because there's no repository called ropensci.r-universe.dev on GitHub, one can deduce that r-universe knows about the builds at ropensci.r-universe.dev/builds because they are on CRAN.

[fkohrt]

@jeroen Just checking whether you received my previous reply :)

[jeroen]

Yes you can rebuild binaries from source later if you have the compilers and build tools available.

For ropensci the registry is here: packages.json. You can find the packages list for any universe by going to https://github.com/r-universe/<name> and then clicking on the submodule named .registry.

For cran packages that do not have a custom registry, the universes are auto-generated from https://github.com/r-universe-org/cran-to-git