[Rd] 'CanMakeUseOf' field [was ".. Add 'fields' argument ..]

[Duncan Murdoch]

On 8/29/2006 10:12 AM, Martin Maechler wrote:
>>>>>> "PaulG" == Paul Gilbert <pgilbert at bank-banque-canada.ca>
>>>>>>     on Tue, 29 Aug 2006 09:55:09 -0400 writes:
> 
>     PaulG> Martin Maechler wrote:
>     >> ...
>     >> 
>     >> The idea was a field related to but weaker than 'Suggests' :
>     >> Something like
>     >> 'canMakeUseOf: <pkg1> [, <pkg2>, ... ]
>     >> which is *not* used in any QA/QC checking, but is purely
>     >> informative: If <pkg1> is require()able, then some examples may
>     >> look nicer, a function may provide another feature, etc, etc.
>     >> Alternatives to 'canMakeUseOf' would have been
>     >> 'isHappilyCoworkingWith' ....
>     >> 
>     >> What do you (R-devel listeners) think about the idea?
> 
>     PaulG> I still like this idea.  I prefer 'canMakeUseOf' to 
>     PaulG> 'isHappilyCoworkingWith'  mainly because it seems less ambiguous.
> 
> Thanks, Paul.
> As you may have guessed I should have put a  " :-) "  beside the
> 'isHappily...' .
> 
> Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
> is rather too long, but before finding the proper term, we should
> agree on usefulness of such a new field.
> Apart from the use of package authors {some could note that
> other packages make use of theirs, without already depending on
> or suggesting them}, it's one of those fields that should help
> in the future to explore (e.g. cluster or neighborhood-graph)
> the growing high-dimensional space of R packages.

I think we need an option to R CMD check rather than a new field in the 
DESCRIPTION.  Currently a package could be mentioned for any of these 
reasons:

1.  To make functions, examples or vignettes work
2.  To allow optional functionality in functions, examples or vignettes.
3.  Because it contains complementary functions.

I don't think we really need to worry about 3:  it should be contained 
in 1 or 2, if reasonably complete examples are given.

Case 1 is handled by Depends.

An author should check case 2 both with and without the suggested 
package.  A user  might be satisfied with a simple check "as things 
currently stand", or might want a stringent check like the author wants. 
  The author can't know that, because it will depend on the user.

So I don't think this is something that should be changed in 
DESCRIPTION.  There should be an option to R CMD check to include or 
exclude packages mentioned in the Suggests entry.  (I'd suggest a 3 
level option:  check as though they are not available, check as 
currently installed, require that they be available.)

Duncan Murdoch