[Rd] if(--as-cran)?

[Duncan Murdoch]

On 12-09-03 11:18 AM, Martin Maechler wrote:
>>>>>> Dirk Eddelbuettel <edd at debian.org>
>>>>>>      on Mon, 3 Sep 2012 09:34:06 -0500 writes:
>
>      > On 3 September 2012 at 00:49, Henrik Bengtsson wrote:
>      > | Hi, see thread "[Rd] Proposal: Mechanism for controlling the amount of
>      > | testing 'R CMD check' performs" on April 8, 2012:
>      > |
>      > |   https://stat.ethz.ch/pipermail/r-devel/2012-April/063809.html
>
>      > Good proposal, somehow I missed that at the time.
>      > Something like this ought be to implemented in R proper.
>
> I agree.... but the CRAN maintainers have to agree too.
>
>
>      > In Rcpp, I am now using a similar
>      > environment-variable-based approach, and it doesn't scale
>      > particularly well if every (large) package does its own thing.
>
> yes, my packages do their own thing too, now, e.g., Matrix
> (not yet released):
>
> doExtras <- interactive() || nzchar(Sys.getenv("R_MATRIX_CHECK_EXTRA")) ||
>      identical("true", unname(Sys.getenv("R_PKG_CHECKING_doExtras")))
>
> and then I use  if(doExtras) { .... }
> but I agree with Henrik that it would make sense to have more
> than just two levels for the amount of testing, not just for CRAN.
>
> An additional, slightly more interesting feature request that
> you may also want in these cases, is the following:
> Assume, that we have a function testingLevel()
> and the following code should only be run, if the testing level
> is 2 or higher
>
> if(testingLevel() > 2) {
>   .......1
>   .......2
>   ........
>   ........
>   .......n
> }
>
> Now what we all really wanted was that the ........ code
> ran just as in toplevel.
> While I think that's almost impossible,
> as the .....1 to .....n must first be parsed all, and then
> evaluated (which is already different from top level),
> I would at least want that  the auto-printing worked like in
> toplevel, so I don't have to write a  print(.) around every
> ......i that would autoprint if in toplevel, and of course does
> *not* autoprint inside if(.) { .. }.
>

I prefer the current scheme where individual tests can be turned on and 
off.  The space of tests is a 2^N factorial space, not a chain of n 
possible levels.

The only problem I see with the current scheme is that code being tested 
can't find out which tests are being run.  In some cases, that's fine: 
there's no point in example code knowing about tests for consistency 
between documentation and implementation.  In other cases it might even 
be a good thing:  do you want packages to be able to hide dependencies 
on non-CRAN packages, for example?

Duncan Murdoch