dealing with package bundles (was RE: [R] Gregmisc)
On Thu, 2005-03-10 at 17:55 +0000, Prof Brian Ripley wrote:
On Thu, 10 Mar 2005, Marc Schwartz wrote:
On Thu, 2005-03-10 at 16:27 +0000, Prof Brian Ripley wrote:
On Thu, 10 Mar 2005, Liaw, Andy wrote:
One problem that I can see is that it seems like once a package bundle is installed, R basically has no knowledge that the packages belong to one bundle, other than the fact that the DESCRIPTION files of the packages have entries that indicate that they are part of a bundle. Are there ways to figure out such information other than checking packageDescription() of all installed packages?
No. As from 2.1.0, install.packages() will install a bundle given the name of a package it contains (at least if the repositories supply the information), so there will be little need for users to know about bundles.
This is likely to be considered a kludgy approach, but one way of linking packages to bundles with a more global approach (as opposed to one package at at time) is the following:
There is code like that in new.packages. The problem is that looking at ca 500 packages is slow, especially on a laptop disc (or at least on the one of mine that has just died) but even on the fast RAIDs on our servers. Brian
On my system, for the first step, which is the more time consuming:
system.time(Pkgs.Installed <- installed.packages()[, c("Package",
"Bundle")], gcFirst = TRUE) [1] 3.56 1.15 4.89 0.00 0.00 That is with 505 installed packages. That's not tragic, but I do have a fast laptop (3.2 Ghz P4, 2 Gb RAM and a 7200 RPM 60 Gb HD). The latter yields about 36 MB/sec for buffered disk reads according to hdparm. I suppose if this were a significant enough issue (yet to be determined), one way of speeding up the process would be to create some type of data structure (ie. a data frame in a .RData file) that gets updated during package installation. The structure could be loaded, updated and then saved for future recall as required. There would presumably need to be some means of integrity checking on it I suppose. Of course the a priori need has to be defined to make it logical to allocate the dev resources to implement something like this. Marc