[R-pkg-devel] help interpreting a response from CRAN

[Ben Bolker]

   And one more (last for a while): presumably there is no way to check 
CRAN windows timing without submitting to CRAN ... ?  (I will obviously 
do my best by doing arithmetic on the tests that I set to be skipped, 
but it would be nice to be able to double-check without wasting 
everyone's time ... I guess if I knew that CRAN submissions would 
*always automatically* be rejected with Windows test times>10 min, I 
could use CRAN submission itself as my test ... but maybe that's a bad 
idea?)

On 11/22/20 4:06 PM, Uwe Ligges wrote:
> Thanks Dirk. Yes, for lme4 the tests for each archiecture take longer 
> than 5 min, so the overall check time exceeds 10 min.
> 
> So one can follow Dirk's advise.
> 
> As a general remark for others who will read this in the future:
> tests should test the software, but it is generally not important to 
> have real world examples. Small data and few iterations are typically 
> sufficient for tests.
> It is also possible to run less important tests only conditionally if 
> some environment variable is set that you only define on your machine.
> 
> Best,
> Uwe Ligges
> 
> 
> 
> 
> 
> 
> 
> On 22.11.2020 20:36, Dirk Eddelbuettel wrote:
>>
>> On 22 November 2020 at 13:44, Ben Bolker wrote:
>> |    My current guess is that the problem is with the too-long check 
>> time on Windows (NOTE: "Overall checktime 18 min > 10 min")
>>
>> Yes.
>> |   I guess I have to get busy setting more tests and examples to 
>> skip-on-CRAN (kind of a pain as there's no low-hanging fruit - other 
>> than the 'testthat' tests, none of the individual test files take 
>> longer than 15sec, although this is doubled because they have to be 
>> run on 386 and x64 ...)
>>
>> It's under your control. You can detect 'are we on Windows' and branch 
>> or, as
>> I do with test runner I use, exit_file("...") based on such conditions.
>>
>> |   An alternative is that this is a confusingly worded message 
>> indicating that there are strong rev dependencies so the package needs 
>> to be further checked? (That seems unlikely as it explicitly asks me 
>> to resubmit)
>>
>> No. If there were any (even false positive ones) they'd be listed there.
>>
>> Hth, Dirk
>>