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

[Richard M. Heiberger]

So I am looking.  and it is even worse than what you suggest.
library()
shows that both HH and microplot are in both the system and personal libraries
Packages in library 'C:/Program Files/R/R-devel/library':
HH Version: 3.1-34
microplot Version: 1.0-15
Everything else in the system library belongs there.
Neither of these is the current CRAN version.

Packages in library 'C:/Users/rmh.DESKTOP-60G4CCO/R/win-library/4.0':
HH Version: 3.1-39 ## 3.1-37 is the current CRAN version
microplot Version: 1.0-42  ## this is the current CRAN version

I removed the ancient HH and microplot from c:/Program Files/R/R-devel/library
I left the correct current versions of both in
c:/Users/rmh.DESKTOP-60G4CCO/R/win-library/4.0

Then I ran the R CMD check again.
R CMD check --run-dontrun --as-cran HH_3.1-39.tar.gz

Very strange results:
"
* checking examples ... ERROR
Running examples in 'HH-Ex.R' failed
The error occurred in:


R Under development (unstable) (2019-12-05 r77528) -- "Unsuffered Consequences"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> pkgname <- "HH"
> source(file.path(R.home("share"), "R", "examples-header.R"))
> options(warn = 1)
> options(pager = "console")
> base::assign(".ExTimings", "HH-Ex.timings", pos = 'CheckExEnv')
> base::cat("name\tuser\tsystem\telapsed\n", file=base::get(".ExTimings", pos = 'CheckExEnv'))
> base::assign(".format_ptime",
+ function(x) {
+   if(!is.na(x[4L])) x[1L] <- x[1L] + x[4L]
+   if(!is.na(x[5L])) x[2L] <- x[2L] + x[5L]
+   options(OutDec = '.')
+   format(x[1L:3L], digits = 7L)
+ },
+ pos = 'CheckExEnv')
>
> ### * </HEADER>
> library('HH')
Error in library("HH") : there is no package called 'HH'
Execution halted
* checking PDF version of manual ... OK
* checking for non-standard things in the check directory ... OK
* checking for detritus in the temp directory ... OK
* DONE

Status: 1 ERROR
See
  'x:/HOME/rmh/HH-R.package/HH.Rcheck/00check.log'
for details.
"

it tested the new version until it got to examples.  Then it wanted to
run the examples
from the system library version.


Next try.
I will copy the current version (3.1-39, the one I am testing) of just
HH to the system library and run the check again.
That works!  It did a proper check of the correct version of the package.

R-devel seems to have a new check.  it is detecting files written not
in the temp directory.
I was doing so in several \dontrun{} examples, but I will fix them
before actually submitting to CRAN.

Thank you Duncan.

Rich


On Tue, Dec 10, 2019 at 2:27 PM Duncan Murdoch <murdoch.duncan using gmail.com> wrote:
>
> (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
>