[Rd] Shy Suggestion?
Gabor Grothendieck
ggrothendieck at gmail.com
Tue Sep 20 16:06:33 CEST 2005
On 9/20/05, Jari Oksanen <jarioksa at sun3.oulu.fi> wrote:
> On Tue, 2005-09-20 at 09:42 -0400, Roger D. Peng wrote:
> > I think this needs to fail because packages listed in 'Suggests:' may, for
> > example, be needed in the examples. How can 'R CMD check' run the examples and
> > verify that they are executable if those packages are not available? I suppose
> > you could put the examples in a \dontrun{}.
> >
> Yes, that's what I do, and exactly for that reason: if something is not
> necessarily needed (= 'suggestion' in this culture), it should not be
> required in tests. However, if I don't use \dontrun{} for a
> non-recommended package, the check would fail and I would get the needed
> information: so why should the check fail already when checking
> DESCRIPTION?
>
Also one could not have any demos that depend on the missing
packages nor vignettes.
1. Note that you can use:
if (require(mypackage)) {
myfunction1()
myfunction2()
}
which will only run my function if mypackage is accessible.
The main downside is that you don't interspersed input and
output but rather it shows the above all at once since its
one statement and then one sees all the output.
2. One could do:
if (require(mypackage)) myfunction1()
if (require(mypackage)) myfunction2()
but that is quite ugly.
3. Another possibility is:
if (!require(mypackage)) myfunction1 <- myfunction2 <- dummyfunction
myfunction1()
myfunction2()
if (!require(mypackage)) myfunction1 <- get("myfunction1", "package:mypackage")
if (!require(mypackage)) myfunction2 <- get("myfunction2", "package:mypackage")
None of these is really entirely satisfactory and I think we need some
better mechanism/solution for situations like this.
Note that this comes up not only in the situation you mention but also
if you are working on a package whose purpose is to interface to
external code since that external code may not be available but you
still want it to pass R CMD check.
More information about the R-devel
mailing list