R-universe features and questions

[wlandau]

I am opening this thread to keep track things we have requested from R-universe.

For now:

• What is the best way to help package maintainers reproduce R-universe checks in the development versions of their packages? Can we borrow actions for this? C.f. How do I reproduce R-universe checks in an individual package repo r-universe-org/help#384

Eventually we will ask for the following, but we won't need these until R-multiverse is ready to scale up to the whole community (much later):

• Continuous revdep checks: Rerun a package's checks whenever a strong dependency updates r-universe-org/help#369
• Clang-ASAN/UBSan/Valgrind checks on ubuntu-latest. (As @jeroen pointed out, there is no simple pass/fail for any of these checks, so we will need to think about this.)
• The ability to add 20000+ packages to the QA and production universes.

[wlandau]

Relevant to revdep checks: https://github.com/r-devel/recheck.

[wlandau]

From today:

1. Use production (+ CRAN) dependencies for community checks: A formal policy to govern how packages enter and leave the production universe #57. The goal is to align community checks with production checks. Both can still use CRAN where necessary.
2. Rename multiverse.r-multiverse.org to community.r-multiverse.org etc.

@shikokuchuo, is this a good time to rename https://github.com/r-multiverse/multiverse to https://github.com/r-multiverse/community?

[shikokuchuo]

I've already updated the GitHub repos. @jeroen is also switching the R-universe side to r-community.r-universe.dev

[shikokuchuo]

The website is also now updated. Jeroen has done a fantastic job so that the front-ends map to the r-multiverse.org subdomains as well, so we can simply refer to community.r-multiverse.org without needing to worry about the corresponding r-universe.dev subdomain.

[wlandau]

EDIT: we no longer need the request below because of #78

Use production (+ CRAN) dependencies for community checks: #57. The goal is to align community checks with production checks. Both can still use CRAN where necessary.

Turns out this is not feasible because R-universe builds and checks in the same step. (Otherwise there would be a lot of unnecessary time spent reinstalling all the dependencies.)

As an alternative, it would be enough for the production universe to simply not publish the new build if a check fails on R-release or R-oldrel. The previous build, whatever version it is, would stay published. But removing the package from packages.json would take it down entirely. Meanwhile the "community" universe always publishes its builds, regardless of check results.

To confirm: @jeroen, is this feasible to do on the R-universe side?

[wlandau]

For the reasons you’ve identified, a failed check would need to block deployment for the entire package. This replicates the CRAN requirement for a package to work cross-platform.

💯 agree.

OTOH we could only deploy updates if all checks pass on all platforms, but that could mean the entire update is blocked by one platform.

That's a good thing. We want to enforce platform-independence as the general rule, with exceptions only on an opt-in basis.

How difficult would it be to add an option for a package to have checks run (and build) only on certain platforms?

I am not sure we need R-universe to do this. Package developers are already familiar with e.g. testthat::skip_on_os("windows"). And if a package compilation is platform-dependent, then it might not belong in production in the first place.

[shikokuchuo]

I am not sure we need R-universe to do this. Package developers are already familiar with e.g. testthat::skip_on_os("windows"). And if a package compilation is platform-dependent, then it might not belong in production in the first place.

What I mean is if that some packages rely e.g. on POSIX interfaces and only build on Linux/Mac. CRAN allows this on a case by case basis. We don't as yet have a policy for this, so I just want to know whether this is likely to be feasible or not. At the moment, if a package does not build on Windows, it will block it for all platforms.

[wlandau]

A pragmatic route may be to require these packages to conditionally compile based on the platform, then alert users of any functionality not supported. I wonder if there are any examples where this is strictly impossible.

[shikokuchuo]

That's a good idea. Those packages can define dummy functions on non-supported platforms, or ones that just call Rf_error() for example, and make the tests conditional on the platform as well.

In that case I'm happy to adopt a policy that requires packages to build and check on all platforms.

[wlandau]

Just noting that we no longer need this specific request above because of #78.

[wlandau]

@jeroen, I have a couple more R-universe questions:

• Is it possible to freeze the current version of R during the quarterly package freeze in Staging?
• In the "Download snapshot" API in https://staging.r-multiverse.org/apis, is it possible to select binaries for r-release without needing to know the current version of R for the given universe?

[wlandau]

From https://cran.r-project.org/bin/windows/base/old/, it looks like most major/minor releases happen around April 20-25 of the year. @shikokuchuo, should we move the 4/15-5/14 staging period to something like 5/1-6/1 to allow the R version upgrade to happen just before the freeze?

[wlandau]

@jeroen, the current snapshot start dates are at https://github.com/r-multiverse/staging/blob/158ba070d0dc324d1bb934ba3161b7e432e64e43/.github/workflows/staging.yaml#L39. We tried to avoid major holidays with these initial times.

[shikokuchuo]

From https://cran.r-project.org/bin/windows/base/old/, it looks like most major/minor releases happen around April 20-25 of the year. @shikokuchuo, should we move the 4/15-5/14 staging period to something like 5/1-6/1 to allow the R version upgrade to happen just before the freeze?

It could be disruptive to require a new version of R right after it's released. So if the 4-15 freeze fixes the then-current version of R, this allows maintainers a couple of months to make necessary adjustments before requiring a new R version for the 7-15 freeze.

[wlandau]

It could be disruptive to require a new version of R right after it's released. So if the 4-15 freeze fixes the then-current version of R, this allows maintainers a couple of months to make necessary adjustments before requiring a new R version for the 7-15 freeze.

Are you saying you are in favor of the current proposed snapshot schedule, which will likely do the spring snapshot just before the next R version is released?

[shikokuchuo]

Yes. So the Summer snapshot would be the first to use the new R version.