[Rd] NOTE: unstated dependencies in examples

[Duncan Murdoch]

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?

Duncan Murdoch