[Rd] NOTE: unstated dependencies in examples

[Uwe Ligges]

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?

Best,
Uwe Ligges




>
> Duncan Murdoch