[Rd] NOTE: unstated dependencies in examples

[Jari Oksanen]

On 14/10/11 16:26 PM, "Duncan Murdoch" <murdoch.duncan at gmail.com> wrote:

> On 14/10/2011 9:18 AM, Jari Oksanen wrote:

>>> 
>> Uwe&  others,
>> 
>> This is OK if you want to identify the cause of the problems. However,
>> the basic problem was that checking required something that is not
>> required: there was one example that was not run, and one case where the
>> loading of the package was not necessary (if(require(<package>))). I do
>> believe that handling this kind of cases is difficult in automatic
>> checking. However, I think they need not be checked: there should be a
>> new case of package reference in addition to 'depends', 'suggests' and
>> 'enhances' -- something like 'benefitsfrom'.
> 
> Users use those declarations when they ask to install dependencies.  If
> you don't declare a dependence on a contributed package, users will have
> to manually install it.
> 
Howdy,

This is a pretty weak argument in this particular case: 'parallel' is not a
contributed package so that you cannot install it. You either have it or you
don't have it. In latter case, nothing happens, but everything works like
usual. In the former case, you may have some new things.

(Having 'parallel' as a contributed package for R < 2.14.0 would be a great
idea but not something I dare to suggest.)

>> This is now actual to me, since I'm adding 'parallel' support to my
>> package, but there seems to be no clean way of doing this with the
>> current checking procedures. I use the 'parallel' support only if the
>> package is available (in R>= 2.14.0, not yet released), and there are
>> multiple cores.
> 
> Temporarily maintain two releases of your package:  one for R < 2.14.0
> that doesn't mention parallel, and one for R >= 2.14.0 that does.  The
> second one should declare its dependence on R >= 2.14.0.  If support for
> parallel is your only change, you don't need to do anything for the
> previous one:  CRAN will not replace it in the 2.13.x repository if the
> new one needs a newer R.
> 
Forking my package was indeed one of the three alternatives I have
considered. In this case forking sounds really weird: for R < 2.13.0 both
forks would work identically. The only difference being how they are handled
by R checkers. 

Cheers, Jari Oksanen
-- 
Jari Oksanen, Dept Biology, Univ Oulu, 90014 Finland
jari.oksanen at oulu.fi, Ph. +358 400 408593, http://cc.oulu.fi/~jarioksa