John Fox wrote:
Dear Uwe,
-----Original Message-----
From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de]
Sent: September-22-09 2:17 PM
To: John Fox
Cc: r-devel@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
