[R-pkg-devel] inconsistent behavior between R CMD check and interactive use

Duncan Murdoch murdoch@dunc@n @end|ng |rom gm@||@com
Sun Dec 8 22:57:58 CET 2019


On 08/12/2019 3:14 p.m., Richard M. Heiberger wrote:
> I am seeing this in
>> version
>                 _
> platform       x86_64-w64-mingw32
> arch           x86_64
> os             mingw32
> system         x86_64, mingw32
> status         Under development (unstable)
> major          4
> minor          0.0
> year           2019
> month          12
> day            05
> svn rev        77528
> language       R
> version.string R Under development (unstable) (2019-12-05 r77528)
> nickname       Unsuffered Consequences
> 
> I also saw this in 2019-12-03 r77513
> 
> 
> In my interactive use I set
>> Sys.setenv("_R_CLASS_MATRIX_ARRAY_"="true")
> to match what --as-cran does for class(matrix(1))
> 
> There are two problems, unrelated I think.
> 
> 1. I have an example which works correctly in interactive use and which
> shows an error under R CMD check.  The error message is the one we now expect
> when class(matrix(1)) is just "matrix".  The error should not be
> triggered when the class
> is c("matrix","array") >
> 
> 2. I export many functions.  Several are not handled correctly during
> R CMD check testing.
> They appear in the NAMESPACE in the source, and also in both the
> Rcheck 00_pkg_src and the Rcheck built package.
> Yet, when those functions are called during the testing of the
> examples, they aren't visible.
> An ls() call inserted into the \examples{} section does not include them.

ls() wouldn't normally see functions exported from packages.  You'd need
ls("package:foo") to see the exports from package foo, and that only 
works after attaching the package.  But examples should be running with 
your package attached during testing, so if that's what you really 
meant, then you do have a problem.

> The functions are visible and work correctly during interactive use.
> 
> 
> I am running a WIndows 10 system inside a Parallels Virtual Machine on
> a Macintosh.
> 
> Has anyone else seen similar misbehavior?
> Or can suggest a repair?

Not seen this, and can't suggest a repair without seeing a reproducible 
example.

Duncan



More information about the R-package-devel mailing list