R-multiverse and Stan packages

R-multiverse is a new repository system for R packages. It’s built on R-universe and GitHub, and It’s a home for packages outside the scope of CRAN/Bioconductor. We host a central Community universe with the latest release of each registered package, and a Production universe with quarterly snapshots of the healthy packages from Community. https://r-multiverse.org has the details.

I’m sharing because I think R-multiverse may be a nice way to distribute packages that use Stan. In fact, bridgestan recently joined (c.f. [R]: install the R package from R-multiverse · Issue #262 · roualdes/bridgestan · GitHub, chore: add bridgestan by eitsupi · Pull Request #221 · r-multiverse/contributions · GitHub). New packages are registered once via pull request (c.f. Contributors – R-multiverse) and then the Community universe automatically picks up the latest releases directly from GitHub/GitLab.

6 Likes

Thanks, Will! I must admit I’m getting more and more confused on the initiatives of R ecosystem. For example, cmdstanr currently is in R-universe. What’s the difference between multiverse and this universe?

1 Like

Thanks for sharing! I have the same question as @yizhang about the difference between R-universe (which we already use for some packages) and this new multiverse. Also tagging @andrjohns since he’s done a lot of the R-universe setup.

R-multiverse builds on top of R-universe, and its goals are different. The Community repository is a single central/unified universe that:

  1. Always distributes releases (branch: "release" in packages.json, not the development version).
  2. Provides one central install.packages() URL that all the packages share. So rather than setting different installation URLs for different packages from different universes, everyone always calls install.packages(repos = c("https://community.r-multiverse.org", ...))

Plus, R-multiverse has its own system for production snapshots of Community.

So R-multiverse is a bit different from R-universe. In fact, it’s actually most similar to Bioconductor, except we have a different package contribution model and we aim for a more general user base.

Does that make sense? R-universe spins up personal/org universes with mostly development versions of packages, whereas R-multiverse has a single universe of releases that everyone shares.

Please let me know if there is anything specific we should clear up at https://r-multiverse.org.

3 Likes

I would love to see something other than Bioconductor and CRAN for distributing R.

Are you looking at versioning and dependencies?

You might want to reconsider the name of this package/project. People are going to be confused with universe vs. multiverse, particularly when your multiverse is described as a single universe.

Are you looking at versioning and dependencies?

In what sense?

You might want to reconsider the name of this package/project. People are going to be confused with universe vs. multiverse, particularly when your multiverse is described as a single universe.

That’s a tough one. After much internal debate, we landed on a name that deliberately points to R-universe. We want people to know that R-multiverse is fundamentally an extension of R-universe, and we want people to know that we’re pro-R-universe and not anti-CRAN. (In fact, most R-multiverse packages have CRAN dependencies.) We considered other names, but we thought they were less clear.

1 Like

In the sense of supporting them. There’s no hard version dependencies in CRAN, which makes it very hard to update because every update has to work with all the versions. This is the main bottleneck for us getting RStan onto CRAN and the reason we only update RStan rarely.

Thanks for clarifying. R-multiverse makes this much easier. Let’s say rstan and StanHeaders are already registered (c.f. Contributors – R-multiverse). To update both packages, just create new GitHub releases (e.g. Releases · stan-dev/rstan · GitHub) before the next Staging cycle (Production repository – R-multiverse). If checks pass using the current versions together, then next Production snapshot will accept them. No need for one package to stay compatible with an old version of the other.

And the Community repository (Community repository – R-multiverse) automatically picks up the latest GitHub release without enforcing R CMD check.

This would be a huge improvement over CRAN and would eliminate most of our issues with new releases of RStan. It doesn’t quite let you lock on an older version of a repo, which you really need to make sure things don’t go stale.

Also not having to comply with external packages unit tests on things like the misspellings error messages would also be a huge win vs. CRAN.

2 Likes

We do ignore NOTEs e.g. misspellings in the DESCRIPTION. As far as R CMD build and R CMD check are concerned, we only enforce ERRORs, WARNINGs, and source build failures, and only on Linux R-devel, Windows R-release, and Mac R-release.