2011/11/25 Uwe Ligges <lig...@statistik.tu-dortmund.de>: > > > On 23.11.2011 14:59, Gabor Grothendieck wrote: >> >> 2011/11/23 Uwe Ligges<lig...@statistik.tu-dortmund.de>: >>> >>> >>> On 23.11.2011 03:18, Gabor Grothendieck wrote: >>>> >>>> On Tue, Nov 22, 2011 at 3:16 PM, Gábor Csárdi<csa...@rmki.kfki.hu> >>>> wrote: >>>>> >>>>> Dear All, >>>>> >>>>> in some functions of my package, I use the Matrix S4 class, as defined >>>>> in the Matrix package. >>>>> >>>>> I don't want to depend on Matrix, however, because my package is >>>>> perfectly fine without Matrix, most of the functionality does not need >>>>> Matrix. Matrix is so included in the 'Suggests' line. >>>>> >>>>> I load Matrix via require(), from the functions that really need it. >>>>> This mostly works fine, but I have an issue now that I cannot sort >>>>> out. >>>>> >>>>> If I define a function like this in my package: >>>>> >>>>> f<- function() { >>>>> require(Matrix) >>>>> res<- sparseMatrix(dims=c(5, 5), i=1:5, j=1:5, x=1:5) >>>>> y<- rowSums(res) >>>>> res / y >>>>> } >>>>> >>>>> then calling it from the R prompt I get >>>>> Error in rowSums(res) : 'x' must be an array of at least two dimensions >>>>> >>>>> which basically means that the rowSums() in the base package is >>>>> called, not the S4 generic in the Matrix package. Why is that? >>>>> Is there any way to work around this problem, without depending on >>>>> Matrix? >>>>> >>>>> I am doing this on R 2.14.0, x86_64-apple-darwin9.8.0. >>>>> >>>> >>>> Try adding these three lines to the package: >>>> >>>> rowSums<- function(x, na.rm = FALSE, dims = 1L) UseMethod("rowSums") >>>> rowSums.dgCMatrix<- Matrix:::rowSums >>>> rowSums.default<- base::rowSums >>>> >>> >>> >>> Folks, please not, just import relevant functionality from the >>> *recommended* >>> package Matrix. >>> Messing around even more is certainly less helpful than importing >>> relevant >>> part from a Namespace/package that you will use anyway. >>> >> >> The real problem is how to deal with conditional dependencies and >> importing is just as much a kludge as anything else. In the problem >> under discussion it has the undesirable property that Matrix is always >> imported even though its almost never needed. >> >> Additional conditional dependency features may be needed in R. All >> the scenarios in which conditional dependency are involved need to be >> thought about since there may be interaction among them. >> >> Some features might be: >> >> - dynamically import another package. >> - uncouple package installation and loading. Right now >> install.packages has a dep= argument that causes the Suggests packages >> to be installed too. There should be some way for the package >> developer to specify this rather than make the user specify it. For >> example, if Matrix were not a recommended package and most users >> wanted to use it in the problem above but a few wanted to use a >> package that conflicts with it then it would be nice if the package in >> question could force dep=TRUE without having the user do it. For >> example, perhaps there would be an >> Installs: Matrix > > > Errr, if I understand this correctly, your arguments are now orthogonal to > your original comments. > > Before you told us it is important to be able to run stuff without having > Matrix available or just load on demand since it may not be available to the > users. Now you tell us you want to make it available without having any need > to use it? >
I was framing this in terms of the Matrix example, but perhaps its easier to understand with the actual example which motivated this for me. That is, the feature is that whenever sqldf is installed then RSQLite is installed too without having RSQLite automatically load when sqldf loads. Currently the only way to arrange that is to put RSQLite into Suggests and then instruct the user to use install.packages(..., dep = TRUE), say. The problem with that is that it burdens the user with this installation detail. sqldf nearly always uses RSQLite so it should be installed when sqldf is without the user having to do anything special. We don't know at install time whether RSQLite will be used or not but are willing to have it unnecessarily installed even if its not needed in order to make it easier for the majority who do use it. However, just because RSQLite is installed does not mean that we want RSQLite to be loaded automatically too. sqldf can determine whether the user wants to use the sqlite backend or one of several other backends and require() RSQLite or not depending on whether its actually to be used in that session. Currently, if RSQLite is in Depends then its always loaded and if its in Suggests then we can't be sure its been installed so neither of these work the way we want. The two things are tied together (i.e. coupled) but here we want to separate them. We always want RSQLite to be installed without making the user specify it on the install.packages() call yet we want the ability to dynamically require() it rather than have it automatically loaded when sqldf is loaded. One way this might be implemented would be to have an Installs: line, say, in the DESCRIPTION file which lists packages which are to be installed at the same time but not automatically loaded. It would be the same as Depends except Depends also loads the package whereas Installs does not -- it only installs the dependency and the package itself has to require it if it wants it loaded. The dynamic part is currently only possible if we use Suggests but that forces the user rather than the package developer to specify whether to install it. (One variation of this is that Installs might only specify that the dependency is installed by default but the user could still override it on the install.packages() call by specifying not to install it.) The point here is that the loading is dynamic but installation always occurs. The Matrix situation was also a situation where dynamic action is important. Its not identical to the sqldf case but I was mentioning them both in case there were any interaction among them since the generic category of dynamic action for package installation and loading might be considered together in case there is interaction among features. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.