Ignore the Additional_repositories field on the staging repo?

[eitsupi]

Related to r-universe-org/help#285

Currently R-universe pulls in dependencies from arbitrary external repositories via the Additional_repositories field. While this is a useful feature for private repositories, it is probably undesirable in the staging universe to install packages from outside the CRAN and staging universes.

The difference with the Remotes field is that Additional_repositories is an officially recognized field in CRAN, and it is not ideal to require each package to not use this field.
Perhaps there should be a setting in the R-universe to ignore Additional_repositories.

[wlandau]

While this is a useful feature for private repositories, it is probably undesirable in the staging universe to install packages from outside the CRAN and staging universes.

I see two sides on this. On the one hand, I agree that Additional_repositories is arguably a back door to dependencies that R-multiverse cannot possibly freeze during Staging. Even worse, if a personal R-universe is one of those repositories, then it could be a development version.

On the other hand, I like what @jeroen has said about keeping things simple and not overcomplicating R-multiverse by trying to catch special cases. I think Additional_repositories is seldom used and seldom causes problems. (Remotes:, on the other hand, is very common, and I am very glad you posted #48.) It is not feasible for R-multiverse checks to read every single DESCRIPTION file. To scale to a reasonable number of packages, we are limited to the information we can get from available.packages() and https://staging.r-multiverse.org/src/contrib/PACKAGES.json. multiverse.internals uses https://staging.r-multiverse.org/src/contrib/PACKAGES.json?fields=Version,License,Remotes,RemoteSha.

[eitsupi]

Thanks for your reply.

I raise this as an issue because, ironically, I believe that the more widespread the use of the R-universe/R-multiverse becomes, the more likely it is that the Additional_repositories-field will be used.

For example, a real-world example might look like this (think of this as a future polars package)

https://github.com/eitsupi/neo-r-polars/blob/776e95621042b7f51947da2544db661d9b34cbab/DESCRIPTION

Package: neopolars
Version: 0.0.0.9000
Depends:
    R (>= 4.2)
Imports:
    rlang (>= 1.1.0)
Suggests:
    arrow
Additional_repositories: https://community.r-multiverse.org

This is an example of using the Additional_repositories field to ensure binary installation of the arrow package, which often causes problems with binary package builds on CRAN.

In this case, the arrow package is definitely not a development version, but is likely to pull in a newer release version than the version in the production repository.

[llrs]

I think R-universe uses the default write_PACKAGES which is then consumed by available.packages. Unrelated to this I was proposing to R-devel to add more fields so that repository users have more information for a complete and correct installation.

However, there is already a way to add more fields to be consumed by available.packages via fields arguments if it is decided to add Additional_repositories (or any other field on the repository).