NOTE: unstated dependencies in examples

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?