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

[Duncan Murdoch]

(Rich, you've heard this already, this message is for others:)

I think I've found the cause of this, and it might be a bug in the check 
code in R.

Rich's package HH "Suggests" microplot, and microplot "Imports" HH. 
When running checks on the new version 3.1-38 of HH it appears the tests 
from the new version are run but the code being run is from the previous 
version 3.1-37 which is on CRAN.   I installed the old version 
indirectly when I installed microplot before running check.

I've only seen this on Windows in R-devel when running --as-cran.  It 
doesn't happen in R-devel on MacOS with or without --as-cran, and I 
don't think it happens on Windows without --as-cran (but it might just 
be that there are no symptoms of testing the wrong version in that case).

A workaround is to explicitly remove HH, then install the new version 
before running the check code.

Duncan Murdoch





On 08/12/2019 10:33 p.m., Richard M. Heiberger wrote:
> Duncan,
> 
> Thank you offering to look.
> I have tried all the obvious things that I could think of.  None helped.
> Perhaps you will think of something I haven't tried
> 
> The reproducible example (not minimal) I can suggest is to use the
> submitted file.
> 
> ftp://CRAN.R-project.org/incoming/archive/HH_3.1-38.tar.gz
> 
> On my windows machine
> 
> R CMD check --as-cran HH_3.1-38.tar.gz
> halts with
>> BB <- likert(tmp[2:6,], box.width=unit(.4,"cm"), positive.order=TRUE)
> Error in apply(x, 3:ldx, function(x) list(x)) :
>    'MARGIN' does not match dim(X)
> Calls: likert ... as.MatrixList -> as.MatrixList.array -> lapply -> apply
> Execution halted
> 
> This is wrong.  That problem was in 3.1-37 and is why I needed a new version.
> I repaired that problem. Running interactively, that command succeeds
> on my machine.
> 
> R CMD check --as-cran --run-dontrun     HH_3.1-38.tar.gz
> halts with
>> tmp.data <- confintervaldata()
> Error in confintervaldata() : could not find function "confintervaldata"
> Execution halted
> 
> That is wrong.  confintervaldata is in the NAMESPACE.
> Running interactively, that command succeeds.
> I added an ls("package:HH") ## yes I spelled it correctly
> and the confinervaldata is missing from the list.  Again, it is in the
> NAMESPACE for the generated executable package.
> 
> 
> On the CRAN machines, neither of these problems appeared.  Instead
> they found a different error
> from code analysis, not from an execution failure.  I don't understand
> why I didn't get that issue on
> my machine when I used --as-cran.  The repair is in 3.1-39, which I
> haven't sent in yet.
> The repair is to replace
> class(xxx) == "try-error"
> with
> "try-error" %in% class(xxx)
> 
> Please let me know if you see these same problems, or if you can think
> of something else to try.
> 
> Rich
> 
> 
> On Sun, Dec 8, 2019 at 4:58 PM Duncan Murdoch <murdoch.duncan using gmail.com> wrote:
>>
>> 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