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

Paul Gilbert pgilbert at bank-banque-canada.ca
Tue Aug 29 19:05:56 CEST 2006



Duncan Murdoch wrote:

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

Well, from "Writing R Extensions"
   The optional  Suggests  field uses the same syntax as  Depends  and 
lists packages that are not
   necessarily needed. This includes packages used only in examples or 
vignettes

So case 1 is handled by the combination of Depends and Suggests, and we 
need something to handle case 2.

The related question is whether the CRAN checks should  try to check 2, 
or perhaps there needs to be 2a and 2b.  There are cababilities (and 
data) that CRAN may not have, so it would be nice distinguish things 
that should be checked on CRAN from things that should not be.

Paul

>
> 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
====================================================================================

La version française suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential inform...{{dropped}}




More information about the R-devel mailing list