[R] On-demand importing of a package

[Uwe Ligges]

On 23.11.2011 16:38, Gábor Csárdi wrote:
> Just for the records, the solution was to make the matrix 'dgCmatrix"
> instead of 'dsCmatrix', 'dgCmatrix' works and 'dsCmatrix' does not. I
> suspect that this has to do something with the S4 class hierarchy in
> Matrix, but I am not sure.
>
> This is a quite ugly workaround, since it depends on some internal
> Matrix features, so I might end up just importing Matrix, as many of
> you suggested in the first place....
>
> However, I agree with Gabor Grotherdieck that the issue is still
> there, in general.
>
> Another example would be (optionally) using the 'snow' (or now
> 'parallel') package. I would like to add optional parallel processing
> to some of my functions in a package, without actually requiring the
> installation of snow/parallel.


Errr, parallel as a base package is *always* installed for R >= 2.14.0.


  If snow is there and the user wants to
> use it, then it is used, otherwise not.
>
> Actually, 'snow' works similarly. It (optionally) calls function from
> the Rmpi package, but Rmpi is only suggested, there is no hard
> dependency. This seems to work well for snow, but in my case I the S4
> features in Matrix interfere.

Well the is an important difference here: Rmpi does not produce name 
clashes and its functionality is found when it is simply attached to the 
search path in the case of snow. The problem with Matrix is that you 
import from base and hence base names are found before Matrix names.
Hence require()ing Matrix as a suggest and calling directly 
Matrix::rowSums explicitly and so on should work. And exactly this is 
what Namespaces are made for: deal appropriately with name clashes by 
importing into the own namespace.

Best,
Uwe Ligges





>
> Gabor
>
> On Tue, Nov 22, 2011 at 8:09 PM, Gábor Csárdi<csardi at rmki.kfki.hu>  wrote:
>> Dear Martin,
>>
>> thanks a lot, this all makes sense and looks great. I suspected some
>> S4 trickery and totally forgot that the base package is imported
>> automatically.
>>
>> Unfortunately I still get
>>
>> Error in callGeneric() :
>>   'callGeneric' must be called from a generic function or method
>>
>> for my real function, but it works fine for the toy f() function, so I
>> think I can sort this out from here.
>>
>> Best Regards,
>> Gabor
>>
>> On Tue, Nov 22, 2011 at 6:57 PM, Martin Morgan<mtmorgan at fhcrc.org>  wrote:
>>> On 11/22/2011 03:06 PM, Gábor Csárdi wrote:
>>>>
>>>> On Tue, Nov 22, 2011 at 4:27 PM, Martin Morgan<mtmorgan at fhcrc.org>    wrote:
>>>> [...]
>>>>>
>>>>> No need to Depend:. Use
>>>>>
>>>>> Imports: Matrix
>>>>>
>>>>> plus in the NAMESPACE file
>>>>>
>>>>>   importFrom(Matrix, rowSums)
>>>>>
>>>>> Why do you not want to do this? Matrix is available for everyone,
>>>>> Imports:
>>>>> doesn't influence the package search path. There is a cost associated
>>>>> with
>>>>> loading the library in the first place, but...?
>>>>
>>>> Not just loading, installing a package has a cost, too. Dependencies
>>>> are bad, they might make my package fail, and I have no control over
>>>> them. It's not just 'Matrix', I have this issue with other packages as
>>>> well.
>>>>
>>>> Anyway, 'Imports: Matrix' is just a workaround I think. Or is the
>>>> example in my initial mail expected to fail? Why is that? Why can I
>>>> call some functions from 'Matrix' that way and why can't I call
>>>> others?
>>>>
>>>>> I'm more into black-and-white -- it either needs Matrix or not;
>>>>> apparently
>>>>> it does.
>>>>
>>>> It's a matter of opinion, I guess. I find it very annoying when I need
>>>> to install a bunch of packages from which I don't use any code, just
>>>> because some tiny bit of a package I need uses them. I would like to
>>>> spare my users from this.
>>>>
>>>> [...]
>>>>>
>>>>> In another message you mention
>>>>>
>>>>>> Matrix:::rowSums(W)
>>>>>
>>>>> Error in callGeneric() :
>>>>>   'callGeneric' must be called from a generic function or method
>>>>>
>>>>> but something else is going on -- you don't get to call methods directly;
>>>>> you're getting Matrix::rowSums (it's exported, so no need for a :::, see
>>>>> getNamespaceExports("Matrix")). Maybe traceback() after the error would
>>>>> be
>>>>> insightful?
>>>>
>>>> Another poster suggested this, that's why I tried. It is clear that I
>>>> should not call it directly. All I want to do is having a function
>>>> like this:
>>>>
>>>> f<- function() {
>>>>   if (require(Matrix)) {
>>>>     res<- sparseMatrix(dims=c(5, 5), i=1:5, j=1:5, x=1:5)
>>>>   } else {
>>>>     res<- diag(1:5)
>>>>   }
>>>>   y<- rowSums(res)
>>>>   res / y
>>>> }
>>>>
>>>> Setting the subjective bit, about depending or not, aside, is there
>>>> really no solution for this? The code in the manual page examples work
>>>> fine without importing the package and just loading it if needed and
>>>> available. Why doesn't the code within the package?
>>>
>>> If I create a package that does not Import: Matrix (btw, Matrix is
>>> distributed with all R), with only a function f, and with exports(f) in
>>> NAMESPACE, I get
>>>
>>>> library(pkgA)
>>>> f()
>>> Loading required package: Matrix
>>> Loading required package: lattice
>>>
>>> Attaching package: 'Matrix'
>>>
>>> The following object(s) are masked from 'package:base':
>>>
>>>     det
>>>
>>> Error in rowSums(res) : 'x' must be an array of at least two dimensions
>>>
>>> This is because (a) Matrix is attached to the user search path but (b)
>>> because f is defined in the NAMESPACE of pkgA, rowSums is looked for first
>>> in the pkgA NAMESPACE, and in then in the search of the package (which
>>> includes base) and then in the user search path. It is found in base, and
>>> the search ends there.
>>>
>>> If I modify f to use  y<- Matrix::rowSums(res) I get
>>>
>>>> f()
>>> Loading required package: Matrix
>>> Loading required package: lattice
>>>
>>> Attaching package: 'Matrix'
>>>
>>> The following object(s) are masked from 'package:base':
>>>
>>>     det
>>>
>>> 5 x 5 sparse Matrix of class "dgCMatrix"
>>>
>>> [1,] 1 . . . .
>>> [2,] . 1 . . .
>>> [3,] . . 1 . .
>>> [4,] . . . 1 .
>>> [5,] . . . . 1
>>>
>>> I start off with the correct rowSums, and continue from there.
>>>
>>> Martin
>>>
>>>>
>>>> Thanks for the patience,
>>>> Gabor
>>>>
>>>>> Martin
>>>>>
>>>> [...]
>>>>
>>>
>>>
>>> --
>>> Computational Biology
>>> Fred Hutchinson Cancer Research Center
>>> 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
>>>
>>> Location: M1-B861
>>> Telephone: 206 667-2793
>>>
>>
>>
>>
>> --
>> Gabor Csardi<csardi at rmki.kfki.hu>      MTA KFKI RMKI
>>
>
>
>