devtools::check_man() 给出错误但 devtools::check() 没有

Question

I'm developing a package ( https://github.com/dpmcsuss/iGraphMatch/ ).

I just started using devtools::check() etc to check for issues. Currently, I'm getting no errors, warnings, or notes (YAY).

Unfortunately, sometimes I want to use devtools::check_man() to just check the documentation for issues since that should be much faster. When I run this I get the following output.

> devtools::check_man()
Updating iGraphMatch documentation
Loading iGraphMatch
Writing NAMESPACE
Writing NAMESPACE
Checking documentation...
Error: cannot source package code:
cannot add bindings to a locked environment

I've tried detaching the package, unloading the namespace, making sure files were not locked, uninstalling the package, .... Nothing seems to make a difference.

If I make a new package everything works fine. I realize this is far from a minimum working example but I'm pretty unsure about where to start looking. Any suggestions would be appreciated. (One thing that I haven't explored yet is whether the order things are documented matters.)

Answer 1

This looks like a bug in R. If you delete all your code except for the setClass in matrix_list.R , you still get the error. If you delete the matrix_list.R file and nothing else, you don't.

This happens if you use tools::checkDocStyle(dir = "iGraphMatch") , you don't need devtools involved at all.

I'd conclude that there's some incompatibility between the tools::checkDocStyle function and S4 methods::setClass . I have no idea if there's a workaround.

Edited to add: There's a fairly simple workaround for this bug. Instead of using the code

matrix_list <- setClass("matrix_list", contains = "list")

in the matrix_list.R file, use this nearly equivalent code:

setClass("matrix_list", contains = "list")

matrix_list <- function(...)
  new("matrix_list", ...)

This avoids triggering the bug in tools::checkDocStyle . It's not quite identical, because the original adds some extra attributes on the generator function, but it should probably be close enough.