Skip to content

Dependencies of Imports not attached?

4 messages · Peter Meilstrup, Simon Urbanek, Martin Morgan

#
On May 7, 2013, at 11:35 PM, Peter Meilstrup wrote:

            
For the record, I see the same problem with other packages that use S4 - very often it trips packages that don't use S4 but import a package that does. The analysis is correct - if a package B just imports a function from another package A which in turn relies on something in Depends, it breaks, because A is not on the search path and thus A doesn't have access to the dependencies it needs. I don't know that was the intended design. I see two way to fix this
1) make sure Depends: are always put on the search path even if the package is not attached
2) automatically generate imports for all packages in Depends:

The main problem is that B is helpless - only a change in A can make it work. Fix for A is to explicitly add import(methods) even though it's already in Depends:. Note that R CMD check doesn't detect this.

Cheers,
Simon
#
On 05/08/2013 10:25 AM, Simon Urbanek wrote:
As described, this is a 'package maintainer' problem -- fix package A. Also, 
this isn't unique to methods, other packages routinely Depend: on something that 
should instead be Import:'ed.

But I think Peter's case is different, because the C implementations of

     SEXP R_do_MAKE_CLASS(const char *what);
     SEXP R_getClassDef  (const char *what);

need to be called from inside the package environment, but there is no way to 
pass the package environment through the interface above.

Maybe the partial patch (attached) points to a solution? It changes the 
interface (though would only break a couple of Bioconductor packages in a minor 
way) (I think there's a missing PROTECT in there too.)

  
    
#
On May 8, 2013, at 1:52 PM, Martin Morgan wrote:

            
By that argument Depends: is unusable. If you specify Depends: you are expressing that your package will work if those packages are on the search path. The fact that R will happily import functions from the package despite that requirement not being fulfilled seems like a bug to me.
Yes, it's the same issue, but a case where adding imports doesn't help because they are not consulted. So in the current setup only 1) is a solution. With your patch, 2) would work as well.
At least currently the PROTECT is not needed because setAttrib() protects its arguments (although there are some dangerous comments in installAttrib ;)).

Cheers,
Simon