On May 8, 2013, at 1:52 PM, Martin Morgan wrote: > On 05/08/2013 10:25 AM, Simon Urbanek wrote: >> >> 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. > > 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. >
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. > 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. > 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. > 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.) > At least currently the PROTECT is not needed because setAttrib() protects its arguments (although there are some dangerous comments in installAttrib ;)). Cheers, Simon > >> >> Cheers, >> Simon >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > -- > Computational Biology / Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N. > PO Box 19024 Seattle, WA 98109 > > Location: Arnold Building M1 B861 > Phone: (206) 667-2793 > <object-env.diff> ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel