[Rd] Re: Packages and Libraries (was: Re: lme4 "package" etc ..)

[A.J. Rossini]

Full agreement.  Thanks, Kurt.


On Thu, 10 Feb 2005 08:53:03 +0100, Kurt Hornik
<Kurt.Hornik at wu-wien.ac.at> wrote:
> >>>>> A J Rossini writes:
> 
> > On Wed, 9 Feb 2005 17:14:08 +0100, Kurt Hornik
> > <Kurt.Hornik at wu-wien.ac.at> wrote:
> >> >>>>> Peter Dalgaard writes:
> >>
> >> > Kurt Hornik <Kurt.Hornik at wu-wien.ac.at> writes:
> >> >> >>>>> A J Rossini writes:
> >> >>
> >> >> > But I don't see a problem with "package("package")", though I'm sure
> >> >> > I'm missing something.
> >> >>
> >> >> package() [sic] might be the creator for package objects, provided we
> >> >> can decide on what they are (and what kind of packages [source,
> >> >> installed, ...] they are used for).
> >> >>
> >> >> usePackage() or use_package() otoh would indicate to "use" a package
> >> >> (i.e., load and attach it).  The tricky part is deciding about the
> >> >> interface (e.g., finally disallowing non-standard evaluation as it is a
> >> >> programmer's nightmare) and what it should return.  And that is work in
> >> >> progress ...
> >>
> >> > Any information on the rate...? (I still vote for usepackage() btw.)
> >>
> >> Why not use(), as the GCD?
> 
> > Excellent suggestion, Kurt.
> 
> And so obvious :-)
> 
> >> > It would be good if we could at least have an outline of the intended
> >> > functionality and see if we could forge ahead and get a preliminary
> >> > version done in time for 2.1.x
> >>
> >> Help us out.
> >>
> >> use <- function(package, pos = 2, lib.loc, ...)
> 
> > use <- function(packageName,pos=2,library, ...)
> 
> > I could argue that "library" and "lib.loc" try to describe the same
> > thing (a name and its pointer).
> 
> We need to decide whether to stay with the "library" concept, or maybe
> go for another one alongside.
> 
> >> where 'package' is either a character string or some sort of package
> >> object/reference, to be specified later.  And 'lib.loc' needs to have a
> >> different name if we rename libraries into stores or whatever ...
> 
> > I think package ought to be a character string.   Unless you want to
> > combine the packageName and libraryLocation into some form of data
> > object, or packageName, libraryLocation, and an environment containing
> > the erstwhile contents?
> 
> For the time being, the package would definitely be specified as a
> character string with its name.  But [RG will like this] I find it
> rather clumsy to have tons of equal-level arguments which in fact could
> use some hierarchical structure.  What we really want is some
> SPECIFICATION of the package to be used, definitely including its name,
> but maybe also where it should come from (library location) or which
> version it should have at least or at most, etc.  So something like
> 
>   use(package_spec("foo", version = ~ > "1.5.8"), pos = 12, ...)
> 
> >> What should this return?  Currently, 'library' returns the list of
> >> loaded (or available) packages by default, as a list of names, which is
> >> not good enough.  So we need something like the DLLInfoList returned by
> >> getLoadedDLLs() (and the docs should actually mention that class), or
> >> something usable by the package management tools ... and this is under
> >> redesign as well.
> 
> > Perhaps "use" should incorporate "require" functionality, i.e. TRUE or
> > FALSE depending on whether you can use it after the "use" function
> > call.
> 
> As Brian said, we would most likely get rid of library() alongside.
> 
> I would condiser the TRUE/FALSE paradigm outdated.  The FALSE case
> really consists of a variety or error conditions, and we should return
> these as such (rather than indicating "oh there was some problem but
> were not telling you which one, unless you are a human reader and look
> at the condition message ...").
> 
> >>
> >> But why should this really return info on all loaded/attached packages?
> >> An alternative might be just returning the package meta-data in some
> >> form.  Or nothing, which would fit into the idea that it really does
> >> nothing apart from loading and attaching a package.
> 
> > I like "libraryContents()" or similar to figure out loaded and
> > potentially loadable packages.
> 
> installed.packages() for the time being.
> 
> >> (And maybe a condition object inheriting from packageLoadAndAttachError
> >> in case of failure? :-))
> 
> > Yes.  whatever.
> 
> -k
> 


-- 
best,
-tony

"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).

A.J. Rossini
blindglobe at gmail.com