Skip to content

advise on Depends

8 messages · Kasper Daniel Hansen, Michael Lawrence, Dirk Eddelbuettel +4 more

Original
1 day later
John Chambers
# 
One additional point to Michael's summary:

The "methods" package itself should stay in Depends:, to be safe.

There are a number of function calls to the methods package that may be included in generated methods for user classes.  These have not been revised to work when the methods package is not attached, so importing the package only may run into problems.  This has been an issue, for example, in using Rscript.

John
On Oct 25, 2013, at 11:26 AM, Michael Lawrence <lawrence.michael at gene.com> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 25 October 2013 at 13:39, John Chambers wrote:

        
| One additional point to Michael's summary:
| 
| The "methods" package itself should stay in Depends:, to be safe.
| 
| There are a number of function calls to the methods package that may be included in generated methods for user classes.  These have not been revised to work when the methods package is not attached, so importing the package only may run into problems.  This has been an issue, for example, in using Rscript.

Right.  

Our command-line / scripting frontend r from the littler package has always
defaulted to loading "methods".  And as r is a small and fully compiled
binary, it still starts up faster than Rscript by a nice margin even though
it has to load the "methods" package.  But who cares about 200 msec.  :)

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

      
On Fri, Oct 25, 2013 at 1:39 PM, John Chambers <jmc at r-project.org> wrote:

            

      
      
      
    

        
To clarify that last sentence for those not aware (and hopefully spare
someone having to troubleshoot this), executing R scripts/expressions
using 'Rscript' rather than 'R' differs by which packages are attached
by default.  Example:

% Rscript -e "search()"
[1] ".GlobalEnv"        "package:stats"     "package:graphics"
[4] "package:grDevices" "package:utils"     "package:datasets"
[7] "Autoloads"         "package:base"

% R --quiet -e "search()"

            

      
      
      
    

        
[1] ".GlobalEnv"        "package:stats"     "package:graphics"
[4] "package:grDevices" "package:utils"     "package:datasets"
[7] "package:methods"   "Autoloads"         "package:base"

Note how 'methods' is not attached when using Rscript.  This is
explained in help("Rscript"), help("options"), and in 'R Installation
and Administration'.

/Henrik

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Paul Gilbert
    

    

      
      #
    

  


  

      
On 13-10-25 05:21 PM, Henrik Bengtsson wrote:

            

      
      
      
    

        
It would be nice to have more detail about when this is necessary, 
rather than suggested as a general workaround. I thought the principle 
of putting things in Imports was that it is safer. I have methods listed 
in Imports rather than Depends in 16 of my packages, doing roughly what 
was the basis for the original question, and I am not aware of a 
problem, yet.

Paul

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      John Chambers
    

    

      
      #
    

  


  

      
Software generated in methods for user classes calls functions in the methods package, as I said.  I don't  know the circumstances (if any) when such calls fail to find functions if  the whole package is  imported.   Perhaps someone on this list may have examples.

But for sure just importing the functions your package calls during installation (setClass(), setMethod(), etc.) won't always be enough.

When the S4 classes and methods were implemented in R in the early 2000s, it was assumed that the methods package would be considered part of the system, as the analogous code was in S.  

It would be nice to either have the package included in Rscript, CMD check, etc. or for some enterprising and very thorough person to go through and bullet-proof the generated code for the absence of the package from the search list.

Absent either of those, the defensive approach is to put methods in Depends.   Or at least, import the package rather than just the obvious functions.

John

        
On Oct 25, 2013, at 3:46 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
On 10/25/2013 11:26 AM, Michael Lawrence wrote:

            

      
      
      
    

        
And also the user should be able to use ? to access the full
documentation of what is public. This means that if your package
defines and exports a method for a generic defined elsewhere, it should
"Depends" on the package where the generic is defined. Same thing if
your package extends a class defined elsewhere.

Cheers,
H.