[Rd] optional package dependency (suggestions/wishes)

[Ross Boylan]

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

2. NEW BEHAVIOR/OPTIONS
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.

3. SIGNIFICANTLY CHANGED BEHAVIOR
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