From rgentlem at fhcrc.org  Tue Sep 20 16:21:37 2005
From: rgentlem at fhcrc.org (Robert Gentleman)
Date: Tue, 20 Sep 2005 07:21:37 -0700
Subject: [Rd] Shy Suggestion?
In-Reply-To: <Pine.LNX.4.61.0509201459490.7077@gannet.stats>
References: <1127222728.21824.15.camel@biol102145.oulu.fi>	<433011BE.8090007@jhsph.edu>	<1127224092.21824.20.camel@biol102145.oulu.fi>
	<Pine.LNX.4.61.0509201459490.7077@gannet.stats>
Message-ID: <43301AF1.9080902@fhcrc.org>



Prof Brian Ripley wrote:
> On Tue, 20 Sep 2005, Jari Oksanen wrote:
> 
> 
>>On Tue, 2005-09-20 at 09:42 -0400, Roger D. Peng wrote:
>>
>>>I think this needs to fail because packages listed in 'Suggests:' may, for
>>>example, be needed in the examples.  How can 'R CMD check' run the examples and
>>>verify that they are executable if those packages are not available?  I suppose
>>>you could put the examples in a \dontrun{}.
>>>
>>
>>Yes, that's what I do, and exactly for that reason: if something is not
>>necessarily needed (= 'suggestion' in this culture), it should not be
>>required in tests. However, if I don't use \dontrun{} for a
>>non-recommended package, the check would fail and I would get the needed
>>information: so why should the check fail already when checking
>>DESCRIPTION?
> 
> 
> Because it is a `check', and it assembles all the information needed at 
> the beginning.  I'd certainly prefer to know at the beginning rather than 
> 20 minutes into running the tests.
> 
> R CMD check is not really for end users: it is for package writers, 
> repository maintainers and for people checking proposed R changes.  Those 
> people want all the checks possible to be done.
> 

   Some of us also want a mechanism similar to this proposal. There are 
situations where the usage is of a minimal nature, the package may not 
be available on all architectures and the package developer is perfectly 
capable of setting up their tests to deal with the presence or lack 
there of. What happens now is that in these sorts of situations 
developers are tending to simply not list the dependency anywhere, and 
that is not a particularly good solution either. I would also point out, 
to those who believe that forcing all dependencies to be declared and 
enforced that name spaces provide a rather large hole.

My understanding of the original intent of Suggests was that it not be 
quite so rigid, but as that has not been how others interpreted it, it 
seems we should have another level of dependency (Uses has been bandied 
about).

  As I recall the discussion it was something like
  Depends:  major functionality in the package will not
      work without other packages listed here

  Suggests:  minor functionality (eg. some functions and or options will 
fail) if these packages are not available

  Uses: package is used for an example, or the current package provides 
an interface to the other package (where else do I put that code?) which
  will be used by anyone wanting to use both

  As I said above, and will try to emphasize, I really do not want R CMD 
check to do any checking of Uses (unless asked to do so). Developers 
that use Uses need to make sure that their package works and passes R 
CMD check whether the package is there or not.

-- 
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
rgentlem at fhcrc.org



[Rd] Shy Suggestion?
Robert Gentleman