"FrL" == friedrich leisch <friedrich.leisch at stat.uni-muenchen.de>
on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:
>> Duncan Murdoch <murdoch at stats.uwo.ca> writes:
>>> I think we need an option to R CMD check rather than a new field
>>> DESCRIPTION. Currently a package could be mentioned for any of
>>> reasons:
>>>
>>> 1. To make functions, examples or vignettes work
>>> 2. To allow optional functionality in functions, examples or
>>> 3. Because it contains complementary functions.
>>>
>>> I don't think we really need to worry about 3: it should be
>>> in 1 or 2, if reasonably complete examples are given.
>>>
>>> Case 1 is handled by Depends.
>>
>> I think there is an important distinction between a dependency
>> for the package to function and a dependency needed to demonstrate
>> said functionality via an example or vignette. The former is what
>> Depends is about, the latter is something else (Suggests).
FrL> Sorry to join in late, I am at the Compstat conference and have
limited
FrL> email access. What Seth describes in the above paragraph is
exactly what I
FrL> had in mind when splitting the single Depends field we had into
Depends
FrL> and Suggests: Depends are a necessity to run the package,
Suggests is nice
FrL> to have but not necessary. If you know how to use a package you
may the
FrL> decide not to install a package that is only suggested, but
FrL> * may not be interested to execute the examples,
FrL> * know that you never need the extra functionality
FrL> * ...
FrL> so it should not be auto-installed unless you ask for
FrL> it (the default could also be the other way round, the
FrL> point is that it should be possible to have package foo
FrL> but not the packages it only suggests). On CRAN we
FrL> check with all suggestions to test all bits and pieces,
FrL> having an option in R CMD check to test only with
FrL> suggests may be nice, if there is use for it.
Yes.
However, I see two (related) problems with the current 'Suggests'
and that's why I opened this thread proposing to have a
(what I now would want to simply call) 'canUse' :
1) For 'R CMD check' (and hence CRAN checking),
Packages in 'Suggests' must be require()able, and
hence all testing only happens *with* the suggested packages
being there, and not without.
2) "Suggests" suggests to the human reader of DESCRIPTION that
the package authors suggest to also install the packages listed
there.
Now there are cases, I (as package author) want to show some
stuff, or even provide compatibility functionality for some
packages that are related to mine, but which I really do not
``suggest''
to also be installed, e.g., because the other packages do
similar stuff as mine, but I believe my package to be
superior. In such a case, I may, e.g., want to provide
functions for porting the other package classes to my package's.
Duncan Murdoch has proposed to take care of "1)" by
still only use 'Suggests' but adding another option to 'R CMD
check', let's say --no-suggests which would run all the
checks without having the suggested packages available
--- something not quite easy to implement, BTW:
Imagine the typical windows users who (AFAICS) always only use
one library into which they install all packages.
How do you want the
if( require(<my_suggested_package>) ) {
...
}
clause *not* to be triggered in such a case ?
I do agree quite a bit that such a '--no-suggests' option would
be very useful for 'R CMD check' -- in addition to my proposal.
Further, I think "2)" above is not taken care of anyway.
After all the interesting statements and alternative proposals,
I'm still proposing to introduce a 'canUse' field for DESCRIPTION
which
a) has a "human-readable intent" of being weaker than 'Suggests'
b) will not require its packages to be available for R CMD check
c) conveys extra information about the package's context, to humans, and
d) will potentially be used in automated or semi-manual
``R package database management''