Thank you all for the kind suggestions! Dirk's advice (in the same spirit
of Hadely's suggestion) should work like a glove !

For the record, I really appreciate how supportive the R community (and
this group in particular) is. Thanks a bunch and happy New Year!

best,
Rafa Pereira

On Tue, Dec 30, 2025 at 2:54 PM Hadley Wickham <[email protected]> wrote:

> 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

Reply via email to