[Rd] NOTE: unstated dependencies in examples

[Jari Oksanen]

On 14/10/11 19:00 PM, "Uwe Ligges" <ligges at statistik.tu-dortmund.de> wrote:

> 
> 
> On 14.10.2011 16:15, Duncan Murdoch wrote:
>> On 14/10/2011 10:10 AM, Jari Oksanen wrote:
>>> 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.
>> 
>> I don't see why it's weird to require that a version that uses a
>> facility that is in 2.14.0 but no earlier versions should have to
>> declare that. Sure, you can put all sorts of conditional tests into your
>> code so that it avoids using the new facility in older versions, but
>> isn't it simpler to just declare the dependency and avoid cluttering
>> your code with those tests?
> 
> Indeed, I think you should update your package and declare the
> dependency on R >= 2.14.0. This seems to be a cleanest possible
> approach. Distributing a contributed parallel package without
> functionality for R < 2.14.0 is not, why should anybody develop code for
> R versions that won't be supported any more in due course?

Here one reason: Our PC labs have now R version 2.12.something and it is not
in my power to upgrade R, but that depends on the will of our computing
centre. If it will upgraded, it will not be 2.14.something. A simple desire
to be able to use the package in the environment were I work sounds a valid
personal reason.

A second point is that the package would not *depend* or anything on R >=
2.14.0. It could be faster in some cases, but not in all. It would just as
legitimate to have a condition, that the package cannot be used by those
poor sods who don't have but one processor (and I was one just a short time
ago). Indeed, this is exactly the same condition: you *must* have a hardware
I want you to have, and the version of R I want to have. I won't make that
requirement.

Like I wrote in my previous message, I had considered three choices. One was
forking, another was delaying the release of these features till 2.14.* is
old, and the third was to depend on 'snow' *and* 'multicore' instead of
'paralle'. Now the second choice sounds the best.

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