Re: [Rd] optional package dependency

From: Simon Urbanek <>
Date: Fri, 15 Jan 2010 10:47:47 -0500

On Jan 15, 2010, at 10:22 , Seth Falcon wrote:

> On 1/15/10 12:19 AM, Kurt Hornik wrote:
>>>>>>> Jeff Ryan writes:
>>> Hi Ross,
>>> The quantmod package makes available routines from a variety of
>>> contributed packages, but gets around your issues with a bit of, um,
>>> trickery.
>>> Take a look here (unless your name is Kurt ;-) ):
> I believe another option is:
> pkg <- "somePkg"
> pkgAvail <- require(pkg, character.only = TRUE)
> if (pkgAvail)
> ...
> else
> ...

That is not an option - that is the code you usually use with Suggests: (except for the pkg assignment which is there I presume to obscure things).

>> But Kurt will we happy to tell you that you can turn off "forcing"
>> suggested packages for checking by setting
>> in your environment. The idea is that maintainers typically want to
>> fully check their functionality, suggesting to force suggests by
>> default.
> Unless the public repositories such as CRAN and Bioconductor decide to
> set this option, it provides no solution for anyone who maintains or
> plans to make available a package through a public R repository such
> as
> CRAN or Bioconductor.
> There is a real need (of some kind) here. Not all packages work on
> all
> platforms. For example, the multicore package provides a mechanism
> for
> running parallel computations on a multi-cpu box, but it is not
> available on Windows. A package that _is_ available on all platforms
> should be able to optionally make use of multicore on non-Windows. I
> don't think there is a way to do that now

... there are 10 packages on CRAN that officially suggest multicore and there is no issue with their checks. I suspect you are making up an issue here that doesn't really exist ...

  As Kurt pointed out the checking is optional and makes sense to test the optional capability. You'd have to ask him but I don't think Kurt refuses packages because they suggest something that is not available everywhere ...

> and pass check without
> resorting to "tricks" as above. These tricks are bad as they make it
> harder to programmatically determine the true "suggests".

Hence I don't see why your should even pst them ;).


> And NAMESPACE brings up another issue in that being able to do
> conditional imports would be very useful for these cases, otherwise
> you
> simply can't make proper use of name spaces for any optional
> functionality.
> I'm willing to help work on and test a solution if we can arrive at
> some
> consensus as to what the solution looks like.
> Best,
> + seth
> ______________________________________________
> mailing list
> mailing list Received on Fri 15 Jan 2010 - 15:57:18 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sat 16 Jan 2010 - 18:20:14 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive