>>>>> Duncan Murdoch writes:
> On 8/29/2006 10:12 AM, Martin Maechler wrote:
>>>>>>> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
>>>>>>> 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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
