【问题标题】:Issues in R package after CRAN asked to replace \dontrun{} by \donttest{}CRAN 要求将 \dontrun{} 替换为 \donttest{} 后 R 包中的问题
【发布时间】:2020-12-20 21:59:39
【问题描述】:

我向 CRAN 提交了一个包,他们要求我将 Rd 文件中的 \dontrun{} 替换为 \donttest{} 并重新提交。我使用\dontrun{} 来包装一些应该抛出错误消息的示例。

在将\dontrun{} 替换为\donttest{} 后,我进行了一些测试,R CMD check 仍然成功,但现在devtools::check()R CMD check --as-cran 都失败了,因为\donttest{} 中包含的示例:

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

经过一番浏览,我了解到 R 4.0.0 已将 R CMD check --as-cran 更改为运行 \donttest 示例。根据R-devel的NEWS

"R CMD check --as-cran 现在运行 \donttest 示例(由 example() 运行)而不是指示测试人员这样做。这可以通过设置环境变量在开发过程中临时规避 R_CHECK_DONTTEST_EXAMPLES 为假值。”

由于我打算将包重新提交给 CRAN,因此在本地将 _R_CHECK_DONTTEST_EXAMPLES_ 设置为 false 对我没有帮助。

我还在 devtools 问题中发现了 this 最近的讨论,其中 Hadley Wickham 指出:

“一般来说,现在如果你不想在 CRAN 上运行测试,\dontrun{} 更有可能工作,但使用 \dontrun{} 可能会导致初始提交失败。”

所以现在我不知道如何继续,因为如果我重新提交带有所需更改的包,我已经知道它会在R CMD check --as-cran 中引发错误,因此它可能会导致 CRAN 的自动预测试失败。

编辑:

按照here 的建议,我尝试使用if(interactive()){} 而不是\dontrun{}。此解决方案在R CMD check --as-crandevtools::check() 中成功,但我认为这不是解决此问题的最合适方法,因为它不适用于example()(引发错误并且不显示其余示例)。 \dontrun{}example() 一起使用效果更好,因为它会打印所有示例,但会删除使用 \dontrun{} 包裹的示例。

【问题讨论】:

  • 我投票结束这个问题,因为它更适合r-package-devel@r-project.org 邮件列表......这是一个管理问题而不是编程问题......
  • "我使用 \dontrun{} 来包装一些应该抛出错误消息的示例。" - 也许只是从示例中删除这些,而是​​将它们用于测试单元测试?或者这些抛出错误的示例是否需要用户理解包?
  • @SteffenMoritz 删除这些示例确实可以修复 R CMD 检查中的错误。但是在这个包中,我有一些函数可以根据某些条件停止执行并显示信息性错误消息,我认为说明这一点会很有用(甚至认为不是必需的)。
  • 发布了一个答案 :) 我经常看到的是,人们在示例中添加内容,但将其注释掉。可能是一个很好的妥协。
  • @SteffenMoritz 你是对的,文档将在我试图不运行的示例行中包含if(interactive()),从这个意义上说,\donttest{} 将导致“更整洁”的文档因为\donttest{} 没有打印出来。但我不认为\donttest{} 在这里是一个选项,因为它会在运行R CMD check --as-cran 时返回实际错误(以及在运行example() 时)。但这与\dontrun 相比仍然是一个改进,因为\dontrun 是也打印到文档中。

标签: r devtools cran


【解决方案1】:

如果你知道某些东西会抛出错误,你可以把它包装在try()中。

## example of failing code
try(stop("Here is an error"))

【讨论】:

  • 感谢您的回答。这似乎是迄今为止最好的解决方案。它在R CMD check --as-cran 中成功并在example() 中正确显示错误消息而不会停止执行。我仍在考虑我的选择,但如果这最终成为实际的解决方案,我会回来接受这个答案。
  • 我现在可以确认 CRAN 接受了这个解决方案。
【解决方案2】:

我认为包示例不适合放置“应该抛出错误消息的示例”

当您将这些“示例”移至testthat 单元测试时,您的问题将很容易解决。

expect_error()
expect_warning()

查看您的包是否按预期抛出警告/错误。

如果您真的想告知用户他们应该避免输入的内容,也许您可​​以将其作为注释添加到示例或其他文档中(详细信息、参数)

您在其他包示例中经常看到的内容如下:

## 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

【讨论】:

  • 感谢您的回答!我已经在使用单元测试来确保错误消息符合预期(除其他外)。我提到的错误消息并不是要告诉用户应该避免什么样的输入。想象一下helper_foo(x, y),您在foo(x, y) 中使用它来停止foo() 的执行,以防xy 的某些条件是TRUE,并通知用户哪些条件触发了错误。 helper_foo(x, y) 是一个函数,而不仅仅是嵌入在 foo() 中的代码,因为它可以用于许多其他具有类似输入结构的函数。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2017-06-05
  • 1970-01-01
  • 2021-05-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-12-19
相关资源
最近更新 更多