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{}
.
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"))
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With