Closed eitsupi closed 3 weeks ago
I do not think this would be possible to handle in the QA universe at https://r-multiverse.r-universe.dev, but we could easily screen https://r-multiverse.r-universe.dev/src/contrib/PACKAGES.json?fields=Remotes for "Remotes"
as part of #10.
I do not think this would be possible to handle in the QA universe at r-multiverse.r-universe.dev
Of course this would be a feature request to R-universe, but I suppose we could disable Remote packages across the universe, or configure it to ignore the Remotes field for certain packages.
Of course this would be a feature request to R-universe
I'm not sure this would be a good fit with R-universe more broadly. On the R-multiverse side, I think we can handle these cases by adding extra checks to https://github.com/r-multiverse/checks, communicating those checks in an opt-in notification system, and excluding those packages from the production universe (all work planned for the future). In the meantime, I started https://github.com/r-multiverse/help/discussions/49 to brainstorm other R-multiverse-side checks.
To clarify: the intent of the QA universe (currently https://r-multiverse.r-universe.dev) is to accept all package releases regardless of problems. These are packages endorsed by the maintainer but not necessarily ready for production: https://r-multiverse.org/about.html#the-quality-assurance-qa-for-r-packages
Since R-universe takes the
Remotes
field into account, I noticed that there is a possibility that the development version of the package will be pulled into the R-multiverse.For example, the development version of the
SBC
package is currently deployed. This isn't ideal, right?From here:
https://github.com/r-universe/r-multiverse/blob/ed7fc29a968eff65aacbf256a6183d3389b3f8f7/.remotes.json#L2-L7 https://github.com/ropensci/stantargets/blob/bbdda1b4a44a3d6a22041e03eed38f27319d8f32/DESCRIPTION#L70-L71