Skip to content

Shy Suggestion?

12 messages · Jari Oksanen, Roger D. Peng, Brian Ripley +6 more

Original
Jari Oksanen
# 
The R-exts manual says about 'Suggests' field in package DESCRIPTION:

"The optional `Suggests' field uses the same syntax as `Depends' and
lists packages that are not necessarily needed."

However, this seems to be a suggestion you cannot refuse. If you suggest
packages:

(a line from DESCRIPTION):
Suggests: MASS, ellipse, rgl, mgcv, akima, lattice

This is what happens:

$ /tmp/R-alpha/bin/R CMD check vegan
* checking for working latex ... OK
* using log directory '/home/jarioksa/devel/R/vegan.Rcheck'
* using R version 2.2.0, 2005-09-19
* checking for file 'vegan/DESCRIPTION' ... OK
* this is package 'vegan' version '1.7-75'
... clip ...
* checking package dependencies ... ERROR
Packages required but not available:
  ellipse rgl akima

In my cultural context suggesting a package means that it is not
necessarily needed and the check should not fail, although some
functionality would be unavailable without those packages.  I want the
package to pass the tests in a clean standard environment without
forcing anybody to load any extra packages. Is there a possibility to be
modest and shy in suggestions so that it would be up to the user to get
those extra packages needed without requiring them in R CMD check?

I stumbled on this with earlier versions of R, and then my solution was
to suggest nothing. 

cheers, jari oksanen
Roger D. Peng
# 
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{}.

-roger
Jari Oksanen wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Jari Oksanen
    

    

      
      #
    

  


  

      
On Tue, 2005-09-20 at 09:42 -0400, Roger D. Peng wrote:

            

      
      
      
    

        
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?

cheers, jari oksanen

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Tue, 20 Sep 2005, Jari Oksanen wrote:

        

            

      
      
      
    

        
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.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Roger D. Peng
    

    

      
      #
    

  


  

      
I think the reason is that the standard for 'R CMD check' is that examples in 
help pages are guaranteed to be executable by the user (as long as the 
requirements are met).  There is no way to guarantee this without having the 
packages installed.  So strictly speaking, the 'Suggested' packages are not 
needed by the *user*, but are needed by the *maintainer*.

Perhaps, you differ with the standard itself, but I personally think it's a good 
one.

-roger

        
Jari Oksanen wrote:

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Gabor Grothendieck
    

    

      
      #
    

  


  

      
On 9/20/05, Jari Oksanen <jarioksa at sun3.oulu.fi> wrote:

            

      
      
      
    

        
Also one could not have any demos that depend on the missing
packages nor vignettes.

1. Note that you can use:

if (require(mypackage)) {
  myfunction1()
  myfunction2()
}

which will only run my function if mypackage is accessible.
The main downside is that you don't interspersed input and
output but rather it shows the above all at once since its
one statement and then one sees all the output.

2. One could do:

if (require(mypackage)) myfunction1()
if (require(mypackage)) myfunction2()

but that is quite ugly.

3. Another possibility is:

if (!require(mypackage)) myfunction1 <- myfunction2 <- dummyfunction
myfunction1()
myfunction2()
if (!require(mypackage)) myfunction1 <- get("myfunction1", "package:mypackage")
if (!require(mypackage)) myfunction2 <- get("myfunction2", "package:mypackage")

None of these is really entirely satisfactory and I think we need some
better mechanism/solution for situations like this.

Note that this comes up not only in the situation you mention but also 
if you are working on a package whose purpose is to interface to 
external code since that external code may not be available but you
still want it to pass R CMD check.

  
  


  


      

    

    

      
      

        


  

        

      Achim Zeileis
    

    

      
      #
    

  


  

      
On Tue, 20 Sep 2005, Jari Oksanen wrote:

        

            

      
      
      
    

        
My understanding is that `suggests' only gives suggestions for the user
not the developer. This means that if you as the developer run R CMD check
you need to have the suggested packages available (in order to check all
code in the examples/vignettes/etc.) but the user does not have to have
them for installing/attaching the package.

For example, in my packages if frequently have examples of type

  if(require(foo)) {
    x <- foo(...)
    bar(x)
  }

where foo is a suggested package. This code would never be R CMD checked
if I just don't install the package myself.

Best,
Z

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Robert Gentleman
    

    

      
      #
    

  


  

      
Prof Brian Ripley wrote:

            

      
      
      
    

        
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.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Seth Falcon
    

    

      
      #
    

  


  

      
On 20 Sep 2005, rgentlem at fhcrc.org wrote:

            

      
      
      
    

        
One of the potential gotchas with the current Suggests and R CMD check
setup is that developers cannot easily test whether or not their package
behaves well (e.g. the examples fail gracefully) when packages listed
in Suggests are not available.

As a package developer, I'd like easy ways to check my package under
the "everything is there" scenario and under the "only the minimum
requirements are available" scenario.

+ seth

  
  


  


      

    

    

      
      

        


  

        

      Paul Gilbert
    

    

      
      #
    

  


  

      
Seth Falcon wrote:

        

            

      
      
      
    

        
I suspect a lot of us are doing this by using

            

      
      
      
    

        
and not putting foo in "Suggests."  Robert's solution will solve this by 
having us put foo in "Uses," but then will "Suggests" still have a 
purpose?  Perhaps it would be better just to return to what many of us 
thought was the original meaning of "Suggests."

I related problem is that if there are circular "Suggests" I think there 
is a problem.

Paul

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Kurt Hornik
    

    

      
      #
    

  


  

          

      
      
      
    

        
Those who really want to run R CMD check without forcing the suggestions
can do so via setting the "internal" environment variable
_R_CHECK_FORCE_SUGGESTS_ to something "false", the test is via

  if(!identical(as.logical(Sys.getenv("_R_CHECK_FORCE_SUGGESTS_")),
                FALSE))

If people feel very strongly about this, we could turn this into a check
profile variable to be set in ~/.R/check.conf.  Personally, both as a
developer and a CRAN maintainer I see little need in not forcing the
suggested packages at check time, as in both scenarios I prefer to act
as defensively as possible.

-k

  
  


  


      

    

    

      
      

        


  

        

      Jari Oksanen
    

    

      
      #
    

  


  

      
On Tue, 2005-09-20 at 10:03 -0400, Roger D. Peng wrote:

            

      
      
      
    

        
I am not sure this is a standard by design, but it rather seems to be an
"industrial standard" or a "de facto" standard because of the way its
check is implemented. However, I've learnt that my assumption about the
meaning of 'Suggests' was wrong, and I'll correct my beliefs and work
accordingly.

This was what I assumed: I have 203 functions, and five of these need
non-recommended packages. Many a user never notices any of these
functions, but I thought it might be polite to hint (or "suggest") that
they may (but need not) download some extra packages. Obviously
'Suggests' field can be used for this, but it seems to be used to so
many other and different purposes that using it for hinting is hardly
sensible.  To summarize the responses, 'Suggests' has following uses:

1. It actually is meant for maintainers instead of the users, and
therefore it should list all packages that the package depends on. It is
not 'Depends', though, since those packages are not attach'ed. There for
missing 'Suggests' packages is an ERROR.

2. 'Suggests' also should be used for 'BuildRequires' (since there in no
field of that name). Both the R-exts manual and several responders said
that 'Suggests' should contain those packages that are needed to, say,
build the package vignettes. After building these vignettes, those
packages are never needed, and won't be needed by users of binary
packages. Therefore agian the ERROR.

This was not a complaint nor a suggestion to change the tools, but only
an observation. I'm quite willing to work with this set of rules and
I'll comply with them. Again, the grammar confused me, since I didn't
know that suggestions are so absolute (even though I'm married).

cheers, jari oksanen