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-pkg-devel] CRAN policies with regards to runnable examples
4 messages · Jim Hester, Dr. rer. nat. Michael Thrun, Hong Ooi +1 more
Hello Jim, thank you for asking this question. I would also like to have a standard solution for this problem. Best Regards Michael Michael Thrun Postdoctoral Scholar Databionics AG, Mathematics and Computer Science Philipps-Universit?t Marburg Hans-Meerwein-Stra?e 6, 04A28 D-35032 Marburg Phone +49 6421/ 28 23922 www.uni-marburg.de/fb12/datenbionik/
On 1. Oct 2019, at 19:37, Jim Hester <james.f.hester at gmail.com> wrote:
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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
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-bounces at r-project.org> On Behalf Of Jim Hester
Sent: Wednesday, 2 October 2019 3:37 AM
To: R Package Development <r-package-devel at 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 at 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
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 at 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-bounces at r-project.org> On Behalf
Of Jim Hester
Sent: Wednesday, 2 October 2019 3:37 AM
To: R Package Development <r-package-devel at 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 at 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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel