[Rd] NOTE: unstated dependencies in examples

[Uwe Ligges]

On 14.10.2011 18:52, Jari Oksanen wrote:
> 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.


So other people from the administration tell you which software to use 
for teaching? And what happens if they tell you only Excel is available? 
... weird ...


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

You can still use the old version there, if the new version depends on R 
 >= 2.14.0. The old version will stay in the binary repositories for old 
versions of R and in the package archives of the source repository as 
well. I think Duncan explained that already.


> A second point is that the package would not *depend* or anything on R>=
> 2.14.0.

But it depends on it: it won't pass the checks for 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.

Why is the hardware relevant to use the parallel (or your) package? You 
can also use it with one cpu.

Best,
Uwe


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