One motivation behind the policy might be that package failures are an important diagnostic for changes to R itself. Your package should not trigger an R CMD check failure because of a problem with an internet resource, even if it is in principle correct to emit an error, since the sudden appearance of a package failure might indicate that a recent change to R is not backwards-compatible. It is not really about whether your logic is right or wrong but whether your package is constructed in such a way that failures are connected to code changes.
In short, your package should pass R CMD check independently of outside resource availability. On Tue, 30 Dec 2025 at 11:35, Rafael H. M. Pereira <[email protected]> wrote: > > Hi all, > > I would very much appreciate your thoughts on this situation. > > # context > I received an email from Prof Ripley saying that my package is not "falling > gracefully". Error report here > https://www.stats.ox.ac.uk/pub/bdr/Rblas/ATLAS/aopdata.out > > The error happens in the code below. You see, in the case of an internet > connection issue, the aopdata::read_population() function returns a silent > NULL plus an informative message, as it should. So my package does in fact > fail gracefully whenever an internet connection is unavailable. > > In this case, though, the error is actually happening in the ggplot2 call. > Because the df object is NULL, ggplot2 cannot find the "P001" column. In > short, the package itself does follow CRAN's policy when there is an > eventual internet connection issue, but the subsequent code throws an error > in such a case. > > Given this behavior, I’m not sure there is a change I could make to my > package that would fully prevent this situation, other than removing > vignettes that demonstrate how to use the function outputs, which I would > prefer to avoid if possible. > > # the situation > When I asked for advice, a kind Cran maintainer said: "So it is not good > enough to have a function return NULL when the subsequent code will throw > an error when it gets that NULL." > > So here is the situation. The Cran Policy (see it below) requires *the > package* to fail gracefully. It does not mention subsequent code. Imho, it > should not require any subsequent code to fail gracefully. As a > package developer, I only have control over the functioning of my package, > I cannot control what code users will use to analyze the output of my > package functions. > > If necessary, I will simply not run the ggplot calls in my vignettes and > render pre-generated plots saved in .png. I feel this would be a bad > solution to keep the package on CRAN, though. I would really appreciate > your thoughts on this. > > best, > Rafael Pereira > > *Cran Policy asks that:* > > - Packages which use Internet resources should fail gracefully with > an informative > message if the resource is not available or has changed (and not give a > check warning nor error) > > > # code causing the error > > library(aopdata) > library(ggplot2) > df <- aopdata::read_population > <https://ipeagit.github.io/aopdata/reference/read_population.html>( > city = 'Fortaleza', year = 2010, geometry = TRUE, showProgress = > FALSE ) > > > > ggplot() + > geom_sf(data=subset(df, P001>0), aes(fill=P001), color=NA, alpha=.8) + > scale_fill_distiller(palette = "YlOrRd", direction = 1)+ > labs(title='Population distribution', fill="Total population") + > theme_void() > > > best, > Rafael Pereira > > [[alternative HTML version deleted]] > > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
