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

[Duncan Murdoch]

This post contains two incorrect statements.  Since Martin is too busy 
to post a retraction, I will point them out:

  --timings and --as-cran do not set _R_CHECK_TIMINGS_ in the same way.

As far as I recall, nobody has suggested that package writers be limited 
to two choices for test suites.  I certainly haven't.

Duncan Murdoch

On 05/09/2012 6:25 AM, Martin Maechler wrote:
> >>>>> 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