Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Issues in R package after CRAN asked to replace \dontrun{} by \donttest{}

Tags:

r

cran

devtools

I submitted a package to CRAN and they asked me to replace \dontrun{} by \donttest{} in the Rd-files and resubmit. I was using \dontrun{} to wrap some examples that are supposed to throw error messages.

After replacing \dontrun{} by \donttest{} I conducted some tests and R CMD check still succeeds but it happens that now both devtools::check() and R CMD check --as-cran fail due to the examples wrapped in \donttest{}:

checking examples with --run-donttest ... ERROR

After some browsing I learned that R 4.0.0 has changed R CMD check --as-cran to run \donttest examples. According to the NEWS of R-devel:

"R CMD check --as-cran now runs \donttest examples (which are run by example()) instead of instructing the tester to do so. This can be temporarily circumvented during development by setting environment variable R_CHECK_DONTTEST_EXAMPLES to a false value."

Since I intend to resubmit the package to CRAN, setting _R_CHECK_DONTTEST_EXAMPLES_ to false locally will not help me.

I also found this recent discussion in a devtools issue where Hadley Wickham states that:

"Generally, now if you don't want to run tests on CRAN \dontrun{} is more likely to work, but using \dontrun{} may cause initial submission to fail."

So now I don't know how to proceed because if I resubmit the package with the required changes I already know it will throw an error in R CMD check --as-cran, and hence it will probably fail CRAN's automatic pretests.

EDIT:

As suggested here I tried if(interactive()){} instead of \dontrun{}. This solution succeeds in R CMD check --as-cran and devtools::check() but I don't think it is the most appropriate way to address this problem since it does not work well with example() (throws an error and does not show the remaining examples). \dontrun{} works better with example() as it prints all the examples but comments out the ones wrapped with \dontrun{}.

like image 278
Pedro Fonseca Avatar asked Sep 01 '20 18:09

Pedro Fonseca


2 Answers

If you know that something will throw an error, you can wrap it in try().

## example of failing code
try(stop("Here is an error"))
like image 172
Hong Ooi Avatar answered Nov 19 '22 23:11

Hong Ooi


I don't think the package examples are the right place for "examples that are supposed to throw error messages".

Your problem would be easily solved when you move these 'examples' to testthat unit tests.

There is

expect_error()
expect_warning()

to see if your package throws a warning/error as expected.

If you really want to inform users about what they should avoid to input, maybe you can just add it as a comment to the examples or into the other documentation (details, param)

What you see quite regularly in other package examples is the following:

## Example for working
function(x, abc = "5)

## This would give an error because
# function(x, abc = "falsch")

## Working example 2
function(x)
x <- x+y
like image 31
Steffen Moritz Avatar answered Nov 19 '22 23:11

Steffen Moritz