My experience is somewhat similar to that of Hong Ooi.
An initial submission got refused. During resubmission I explained the
necessity of \dontrun{} in certain cases and it was accepted. So the basic
policy here is 'comply or explain'.
>From now on, when I need to place a \dontrun{} anywhere, I will at initial
submission already use the 'Optional Comment' box to document why each
\dontrun{} is necessary. Based on my earlier experiences, this seems
reasonable and also the fastest way to publication.
Best,
Mark
On Wed, Oct 2, 2019 at 5:31 AM Hong Ooi via R-package-devel <
r-package-devel@r-project.org> wrote:
> Hm, up to now my AzureR packages haven't met with any issues, and they are
> basically API wrappers.
>
> I did have one reviewer ask for runnable examples when I submitted one
> package, but replying and pointing out the issues you mention cleared
> things up. I did cc Uwe Ligges in the reply, who approved the other
> packages in the first place -- the other reviewer probably just wasn't
> aware that I'd cleared things with Uwe previously.
>
>
> -----Original Message-----
> From: R-package-devel <r-package-devel-boun...@r-project.org> On Behalf
> Of Jim Hester
> Sent: Wednesday, 2 October 2019 3:37 AM
> To: R Package Development <r-package-devel@r-project.org>
> Subject: [R-pkg-devel] CRAN policies with regards to runnable examples
>
> CRAN reviewers have somewhat recently been requesting that new submissions
> have runnable examples. This is in general a good recommendation, but the
> reviewers seem to apply this policy unconditionally, and there are certain
> classes of packages where this is either extremely cumbersome or impossible
> to do.
>
> Two in particular are packages which wrap web APIs and packages containing
> shiny applications. Even the most robust APIs will inevitably have network
> failures, causing spurious failures on CRAN's machines, and often the APIs
> require credentials to access, which won't be available on the build
> machines. Shiny applications block the R process and require user
> interaction in a browser to function, they cannot really be run
> non-interactively.
>
> In these cases it seems appropriate to put examples in a `\dontrun{}` or
> `\donttest{}` block, and this is what is suggested by writing R extensions.
> However CRAN reviewers have refused to accept packages taking this approach.
>
> If these workarounds are not acceptable what _does_ CRAN want package
> authors to do in these cases?
>
> Jim
>
> ______________________________________________
> R-package-devel@r-project.org mailing list
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=02%7C01%7Chongooi%40microsoft.com%7C1ac67369474848bf7cdc08d746960dd9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637055482613833043&sdata=quC7BH5vtm3I7dWq%2Fhi6FtN54DxrUzO0Z1K9TRc%2FE3c%3D&reserved=0
>
> ______________________________________________
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
