Skip to content

dealing with package bundles (was RE: [R] Gregmisc)

5 messages · Liaw, Andy, Brian Ripley, Marc Schwartz

Original
Liaw, Andy
# 
Given the confusions that some users have regarding package bundles, I'd
like to suggest some changes to how package bundles are handled.

My understanding is that a package bundle is essentially a convenient way to
distribute related packages, so that users can download/install them in one
shot.  However, some users apparently get confused that one can do
install.packages("abundle") but can't do library("abundle").  I think it
might be worthwhile having library() (or it's to-be replacement(s)) do
something more informative, if the argument is the name of a bundle, instead
of a package.  Examples are:

- Give an error that says that's a package bundle, and the constituent
packages need to be loaded individually.

- Load all of the packages in the bundle, but issue an warning.

- (More elaborate) give a menu of packages and ask the user to choose which
one to load.

(Come to think of it, it would be nice for library() to be able to load
multiple packages in one go...)

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?

Cheers,
Andy
Brian Ripley
#
On Thu, 10 Mar 2005, Liaw, Andy wrote:

            

      
      
      
    

        
Just one bundle, AFAICS.

            

      
      
      
    

        
The issue seems only to arise with one bundle that was formerly a package. 
I think re-naming that bundle would be the most effective solution. 
Alternatively, bundle 'gregmisc' could contain a package 'gregmisc' (there 
is an example of that already in CoCo) which told users what had happened 
(or even loaded all the components), which would also work with a rename.

            

      
      
      
    

        
How can you know that?  The names of bundles are not known, and indeed 
`gregmisc' is a perfectly good package name and gregmisc 1.x might be what 
was intended.

            

      
      
      
    

        
In what order, and why, given that library() will already load all the 
dependencies in a sensible order?

            

      
      
      
    

        
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.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Thu, 2005-03-10 at 16:27 +0000, Prof Brian Ripley wrote:

            

      
      
      
    

        
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:

# Get the set of currently installed packages, taking
# just the package and bundle names
Pkgs.Installed <- installed.packages()[, c("Package", "Bundle")]

# Get the packages that are in bundles
# "Bundle" will be NA if package is not in a bundle
Pkgs.Installed[!is.na(Pkgs.Installed[, "Bundle"]), ]


On my system, where I have installed all CRAN packages that do not
require third party libs, I get the following:

            

      
      
      
    

        
Package       Bundle
CoCo        "CoCo"        "CoCo"
CoCoCg      "CoCoCg"      "CoCo"
CoCoCore    "CoCoCore"    "CoCo"
CoCoGraph   "CoCoGraph"   "CoCo"
CoCoObjects "CoCoObjects" "CoCo"
CoCoOldData "CoCoOldData" "CoCo"
CoCoRaw     "CoCoRaw"     "CoCo"
Greene      "Greene"      "Ecdat"
Hayashi     "Hayashi"     "Ecdat"
MASS        "MASS"        "VR"
class       "class"       "VR"
dse1        "dse1"        "dse"
dse2        "dse2"        "dse"
gdata       "gdata"       "gregmisc"
gmodels     "gmodels"     "gregmisc"
gplots      "gplots"      "gregmisc"
gtools      "gtools"      "gregmisc"
nnet        "nnet"        "VR"
spatial     "spatial"     "VR"
svDialogs   "svDialogs"   "SciViews"
svGUI       "svGUI"       "SciViews"
svIDE       "svIDE"       "SciViews"
svIO        "svIO"        "SciViews"
svMisc      "svMisc"      "SciViews"
svSocket    "svSocket"    "SciViews"
svViews     "svViews"     "SciViews"
tframe      "tframe"      "dse"

One could then feasibly manipulate this information as one desires.

HTH,

Marc Schwartz

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Thu, 10 Mar 2005, Marc Schwartz wrote:

        

            

      
      
      
    

        
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

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Thu, 2005-03-10 at 17:55 +0000, Prof Brian Ripley wrote:

            

      
      
      
    

        
On my system, for the first step, which is the more time consuming:

            

      
      
      
    

        
"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