Or slightly simpler (if less helpful), you can do something like:
if (is.null(df)) {
knitr::opts_chunk(eval = FALSE)
}
Hadley
On Mon, Dec 29, 2025 at 7:23 PM Michael Chirico <[email protected]>
wrote:
> At a glance you might try a hidden code chunk that looks for NULL input and
> populates a "fake" dataset if so.
>
> On Mon, Dec 29, 2025, 4:35 PM 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
> >
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [email protected] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
--
http://hadley.nz
[[alternative HTML version deleted]]
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
