From ligges at statistik.tu-dortmund.de  Tue Sep 22 23:00:53 2009
From: ligges at statistik.tu-dortmund.de (Uwe Ligges)
Date: Tue, 22 Sep 2009 23:00:53 +0200
Subject: [Rd] Rcmdr package dependencies
In-Reply-To: <006a01ca3bb5$814591e0$83d0b5a0$@ca>
References: <002001ca3b86$cda835d0$68f8a170$@ca>
	<4AB91497.4020505@statistik.tu-dortmund.de>
	<006a01ca3bb5$814591e0$83d0b5a0$@ca>
Message-ID: <4AB93B05.4020607@statistik.tu-dortmund.de>



John Fox wrote:
> Dear Uwe,
> 
>> -----Original Message-----
>> From: Uwe Ligges [mailto:ligges at statistik.tu-dortmund.de]
>> Sent: September-22-09 2:17 PM
>> To: John Fox
>> Cc: r-devel at r-project.org
>> Subject: Re: [Rd] Rcmdr package dependencies
>>
>>
>>
>> John Fox wrote:
>>> Dear r-devel members,
>>>
>>> My Rcmdr package "depends" on several other packages (tcltk, grDevices,
>>> utils, and car) and "suggests" a number of others (abind, aplpack,
>>> colorspace, effects, foreign, grid, Hmisc, lattice, leaps, lmtest, MASS,
>>> mgcv, multcomp, nlme, nnet, relimp, rgl, and RODBC). The reason for the
>>> distinction is that I don't want all of these packages to load when the
>>> Rcmdr loads; rather, the "suggested" packages are loaded as they're
> needed.
>>> But all of the packages -- both those under "depends" and those under
>>> "suggests" -- really are necessary for all of the features of the Rcmdr
> to
>>> work. For example, if the "leaps" package is absent, then the "Subset
> model
>>> selection" item in the "Models" menu is suppressed.
>>>
>>> This arrangement works reasonably well, but it makes it awkward to
> install
>>> the Rcmdr. If the user issues the command install.packages("Rcmdr"),
> then
>>> the "suggested" packages aren't installed. On the other hand, if the
> user
>>> issues the command install.packages("Rcmdr", dependencies=TRUE), which
> is
>>> what I currently recommend, then "suggested" packages are installed
>>> recursively, causing dozens of packages, most of them actually
> unnecessary,
>>> to be installed. This issue has been growing more acute, and at this
> point
>>> even with a fast Internet connection it takes quite a while for all of
> the
>>> dependencies to download and install.
>>>
>>> I wonder whether I've missed something. Is there a way for me to arrange
>> the
>>> Rcmdr package dependencies so that only the necessary packages (those
>>> currently listed under both "depends" and "suggests" and the packages on
>>> which they "depend") are installed along with the Rcmdr, but the
> currently
>>> "suggested" packages aren't loaded when the Rcmdr loads?
>>
>>
>> Dear John,
>>
>> no, this is not possible.
>>
>> Consider your package A (or Rcmdr) suggests B that suggests C.
>> Then A::foo uses the function B::bar which only works if C::dep is
>> present. B works essentially without C but it requires C just to make
>> bar work. Then this means your A::foo won't work if C is not installed
>> and you won't get it with the setup mentioned above.
>>
>> In summary, I fear what you want might work well *now* (by chance), but
>> it does not work in general.
> 
> I agree that what I want to do isn't bullet-proof. I think, however, that in
> most, if not all, cases, the Rcmdr dialogs will work even if packages
> suggested by currently directly suggested packages were not installed. In
> fact, this is what happens when a package is installed with the default
> dependencies=FALSE. If it turns out that some such indirect dependency is
> actually necessary, I could add that package to those directly suggested
> (were such a mechanism possible). I'd save users a lot of downloads at the
> price of occasionally having to specify a dependency explicitly.


Thanks for the explanation. Unfortunately the current infrastructure 
works with recursive calling with the same arguments. In this case we'd 
need some code that allows to have the first level different from the 
rest of the recursion.
Perhaps one way to go would be to install Rcmdr including its 
dependencies (only) and provide some simple function that installs its 
suggests and their dependencies afterwards if not available. Hmmm, on he 
other hand I do now want to suggest to have yet another mechanism such 
as the biocLite function that I still dislike.

Just some thoughts, best wishes,
Uwe


> Thanks,
>  John
> 
>> Best wishes,
>> Uwe
>>
>>
>>
>>
>>
>>
>>> Any help would be appreciated.
>>>
>>> John
>>>
>>> ------------------------------
>>> John Fox, Professor
>>> Department of Sociology
>>> McMaster University
>>> Hamilton, Ontario, Canada
>>> web: socserv.mcmaster.ca/jfox
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>



[Rd] Rcmdr package dependencies
Uwe Ligges