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

[Deepayan Sarkar]

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


> 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.