Re: [Rd] optional package dependency (suggestions/wishes)

From: Ross Boylan <>
Date: Fri, 15 Jan 2010 10:54:21 -0800

On Fri, 2010-01-15 at 12:34 -0500, Simon Urbanek wrote:
> On Jan 15, 2010, at 12:18 , Ross Boylan wrote:
> > On Fri, 2010-01-15 at 09:19 +0100, Kurt Hornik wrote:
> >> The idea is that maintainers typically want to
> >> fully check their functionality, suggesting to force suggests by
> >> default.
> > This might be the nub of the problem. There are different
> audiences,
> > even for R CMD check.
> >
> > The maintainer probably wants to check all functionality. Even
> then,
> > there is an issue if functionality differs by platform.
> >
> > CRAN probably wants to check all functionality.
> >
> > An individual user just wants to check the functionality they use.
> >
> > For example, if someone doesn't want to run my package
> distributed,
> > but
> > wants to see if it works (R CMD check), they need to be able to
> avoid
> > the potentially onerous requirement to install MPI.
> >
> ... that what's why you can decide to run check without forcing
> suggests - it's entirely up to you / the user as Kurt pointed out ...
> Cheers,
> Simon
This prompts a series of increasing ambitious suggestions:

  1. DOCUMENTATION CHANGE I suggest this info about _R_CHECK_FORCE_SUGGESTS_=false be added to R CMD check --help.

Until Kurt's email I was unaware of the facility, and it seems to me the average package user will be even less likely to know. My concern is that they would run R CMD check; it would fail because a package such as rmpi is absent; and the user will throw up their hands and give up.

I did find a Perl variable with similar name in section 1.3.3 of "Writing R Extensions", but that section does not mention environment variables. It would also be unnatural for a package user to refer to it.

Considering there are many variables, maybe the interactive help should just note that customizing variables (without naming particular ones) are available, and point to appropriate documentation

On even more exotic wish would be to allow a list of suggested packages to check. That way, someone use some, but not all, optional facilities could check the ones of interest. Again, even with better documentation it seems likely most people would be unaware of the feature.

I think the optimal behavior would be for the check environment to attempt to load all suggested packages, but continue even if some are missing. It would then be up to package authors to code appropriate conditional tests for the presence or absence of suggested packages; actually, that's probably true even now.

Ross mailing list Received on Fri 15 Jan 2010 - 19:00:04 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 - 00:10:14 GMT.

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

list of date sections of archive