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

[Martin Maechler]

>>>>> Deepayan Sarkar <deepayan.sarkar at gmail.com>
>>>>>     on Wed, 5 Sep 2012 11:49:37 +0530 writes:

    > On Wed, Sep 5, 2012 at 11:41 AM, Duncan Murdoch
    > <murdoch.duncan at gmail.com> wrote:
    >> On 12-09-04 8:19 PM, Kasper Daniel Hansen wrote:
    >>> 
    >>> On Tue, Sep 4, 2012 at 6:02 PM, Duncan Murdoch <murdoch.duncan at gmail.com>
    >>> wrote:
    >>>> 
    >>>> On 04/09/2012 5:42 PM, Dirk Eddelbuettel wrote:
    >>>>> 
    >>>>> 
    >>>>> On 4 September 2012 at 17:26, Duncan Murdoch wrote:
    >>>>> | On 04/09/2012 5:14 PM, Dirk Eddelbuettel wrote:
    >>>>> | > An add-on argument to the already established option --as-cran may
    >>>>> be
    >>>>> the
    >>>>> | > best.
    >>>>> | >
    >>>>> | > And to iterate, what bugs me is that for _me_ on _my_ machine
    >>>>> developing _my_
    >>>>> | > package I have remember how to enable what is now (as per CRAN's
    >>>>> decree)
    >>>>> | > "non-standard behaviour" of full testing.  I fully agree with what
    >>>>> Terry had
    >>>>> | > said: more tests are better (when we develop).  I want the full
    >>>>> suite
    >>>>> at my
    >>>>> | > end; that is after all why we wrote it!
    >>>>> |
    >>>>> | You don't have to remember that, you need to figure it out once, write
    >>>>> a
    >>>>> | script that sets the environment variables that enable it, and then
    >>>>> you
    >>>>> | can forget it.
    >>>>> 
    >>>>> "In theory, theory and practice are the same. In practice, they are
    >>>>> not."
    >>>>> 
    >>>>> The main test script long had exactly such a setting; I wrote what I
    >>>>> wrote
    >>>>> because it is _still the wrong way around_ and as I happen to have added
    >>>>> to
    >>>>> unit tests this weekend _having suffered through precisely this
    >>>>> setting_.
    >>>>> 
    >>>>> But we are on different wavelengths here and I evidently do not get my
    >>>>> point
    >>>>> across to you.  And as you are the one who could make a change where it
    >>>>> matters, I have no choice but to rest my case in frustration.
    >>>> 
    >>>> 
    >>>> 
    >>>> If you want to give up, then give up, but then don't complain about the
    >>>> current behaviour.  If you want to fix it, then continue the discussion.
    >>>> 
    >>>> You're right that we're on different wavelengths.  If you want some tests
    >>>> to
    >>>> run at home but not on CRAN, then somewhere there has to be a
    >>>> conditional.
    >>>> I'm suggesting that the conditional should be "if there's a tight time
    >>>> limit, skip this".
    >>>> 
    >>>> I don't remember if this was your suggestion, but someone has suggested
    >>>> "if
    >>>> we're running with the --as-cran option, skip this" and others have
    >>>> suggested "if we're running on CRAN, skip this".   I don't see why you
    >>>> find
    >>>> my suggestion so objectionable.  If you want, I'll repeat why I find the
    >>>> other two suggestions objectionable.
    >>> 
    >>> 
    >>> I agree with Duncan that having an option long/short makes more sense
    >>> than with/without cran, as long as cran sets that option to be short.
    >> 
    >>> 
    >>> 
    >>> I would also prefer a command line switch to R CMD check to an
    >>> environment variable, but I'll be very happy with a standardized
    >>> environment variable.
    >> 
    >> 
    >> I honestly don't see the need for a standardized variable.  I've told you
    >> how to detect that you are running --as-cran; if that isn't sufficient
    >> information, then you, the package author, need to set up something more
    >> elaborate, and assume that if it's not set up, then someone else (maybe
    >> CRAN) is running the test.

    > So maybe documenting that (_R_CHECK_TIMINGS_) more formally in R-exts
    > would be sufficient?

    > -Deepayan

yes and no.
As Duncan said very early,  --as-cran is just turning on several
already existing options, one of them being the
_R_CHECK_TIMINGS_  -- which you can *also* enable by  --timings.

So, checking for  _R_CHECK_TIMINGS_ is *not* checking for
the presence of  --as-cran !
.. in the sense that it is necessary but not sufficient.
Also, if I run the "long checks" I may still want to use
 --timings. For me as package developer, the timings may be even more
important in the "long" than in the "short" checks case.

So, one solution that is little work would be that  --as-cran
sets an *extra* environment variable that is *only* set by
--as-cran, but by no other command line switch.

Still a pity that it seems people want to live in a  0/1
setting when it would be very natural to adopt a  0/1/2/3
(or so) one.
It's a bit like prefering  verbose = FALSE/TRUE  as argument to
an R function where eventually I often found that using a
tracing = 0/1/2  (or then  'verbose' = 0/1/2  which is almost
back compatible to FALSE/TRUE) 
was more useful.



    >> I asked the CRAN powers-that-be about the possibility of querying the amount
    >> of time remaining before a timeout; since the different platforms all use
    >> different mechanisms to enforce a timeout, that's not really practical.  So
    >> the best you could hope for is to know that a timeout is in effect.  Before
    >> I wrote any code, I'd need to hear why --as-cran detection isn't sufficient.

I agree that *reliable*  --as-cran  detection  solves the OP's 
and most other correspondents problem.
But as argued above,  _R_CHECK_TIMINGS_  is not sufficient.

Martin