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

[Kurt Hornik]

>>>>> Duncan Murdoch writes:

> 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.)

An internal environment variable called

  _R_CHECK_FORCE_SUGGESTS_

which controls this has been in place for quite some time now.  One can
trivially add a Perl R CMD check configure variable for it.  I am a bit
hesitant to add a --force-suggests cola to R CMD check, as this
hardwires a legacy dependency model which may not be up to future needs.

As an aside, I have never understood whe developers have need for such
an option (as I would have assumed that they'd typically try to check
all of their code).

-k