On May 7, 2013, at 11:35 PM, Peter Meilstrup wrote:
> Encountered an error in scripting, which can be reproduced using Rscript as
> follows:
>
> $ Rscript -e "library(httr);
handle('http://cran.r-project.org')"
>
> Error in getCurlHandle(cookiefile = cookie_path, .defaults = list()) :
> could not find function "getClass"
> Calls: handle -> getCurlHandle
>
> or by starting R without the methods package attached:
>
> $ R_DEFAULT_PACKAGES=base R
> [snip]
>> library(httr)
>> handle('http://cran.fhcrc.org/')
> Error in getCurlHandle(cookiefile = cookie_path, .defaults = list()) :
> could not find function "getClass"
>
> As far as I can tell the error occurs when getCurlHandle .Calls a C
> function which then calls SET_CLASS, which (I guess) requires
> methods::setClass to be in the search path.
>
> Now 'httr' Imports 'RCurl' which Depends on
'methods'. So I think
> `library(httr)` should end up attaching 'methods' to the search
path, but
> it seems 'methods' is just imported to RCurl's namespace.
>
> I think this is a problem since the Depends line is indicating that
> 'methods' must be attached for RCurl to work, whether or not RCurl
itself
> is being attached.
>
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