>>>>> "Seth" == Seth Falcon <[EMAIL PROTECTED]>
>>>>> on Wed, 30 Aug 2006 07:06:24 -0700 writes:
Seth> Kurt Hornik <[EMAIL PROTECTED]> writes:
>> 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).
Seth> This is not an aside, but the heart of the issue IMHO :-)
Seth> One case in which checking Suggests does not make sense is when a
Seth> package provides optional functionality that is platform specific. A
Seth> given Suggests entry may only be available on platform A, but it still
Seth> is desirable to check the package on platform B. Similar issues can
Seth> arise during development when a given Suggests entry stops working
Seth> with R-devel.
Seth> Further, if an item in Suggests means it is optional, then one
Seth> _should_ test that by testing the package without the optional packge
Seth> being available. There are a few ways for a true dependency to sneak
Seth> into the code. So I agree that typically developers want to test all
Seth> of their code, but that implies being able to check a package without
Seth> its Suggests being available (I realize this may be hard to implement,
Seth> but easily having R CMD check ignore Suggests is a good start).
Seth> And lastly, Suggests is currently used to list packages used for
Seth> extended examples in package vignettes and being able to easily
Seth> perform all other checks makes sense to me.
Very good points, thanks.
I think it's clear that some R developers see a clear need for
this and their (our) output would be enhanced by such a very
small addition --- it would probably only be a small addition
addition to the "Writing R Extension" manual for the moment.
I don't understand why some developers have such a resistance
to allow one other such keyword.
Dirk mentioned 'Enhances' --- something which I could also live
with instead of 'CanUse' -- I just to be generous
with myself (as package author) in my interpretation of
"enhancing" :-)
Those developers who cannot remember disambiguating more than
one field for 'optional' are well allowed to keep using just
one, i.e., 'Suggests'.
But others who want to be more precise and or want to better expose
(via DESCRIPTION) what they do anyway
(via 'if(require(*)) { .. }') inside their code, examples, and
or vignettes would just converge on *how* the new field should
be baptized.
Since 'R CMD check' is not affected, there's no other
consequence for any package writer.
Having a much more expressive scheme, namely also specifying where
and how the 'canUse' packages are made use of,
could be even more useful.
However, given the overall reactions and the average package
writer's inertia or even "I don't want to have to know this as
well, I just want my package out" mind set -- which can
perfectly make sense, BTW --
I think we should strive for Einstein's
"Make everything as simple as possible, but not simpler"
here.
I'd really like to conclude this thread or at least concentrate
on the "how" rather than the "do we need this at all?" part.
Martin
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
