[Rd] optional package dependency

[Uwe Ligges]

On 15.01.2010 16: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
>        ...
>
>
>> But Kurt will we happy to tell you that you can turn off "forcing"
>> suggested packages for checking by setting
>>
>>    _R_CHECK_FORCE_SUGGESTS_=false


Seth,

the Windows checks for CRAN run with that setting, i.e.

  _R_CHECK_FORCE_SUGGESTS_=false

Hence the multicore issue mentioned below actually does not exist.

Best,
Uwe



>> 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 and pass check without
> resorting to "tricks" as above.  These tricks are bad as they make it
> harder to programmatically determine the true "suggests".
>
> 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
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel