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

A J Rossini writes:

On Wed, 9 Feb 2005 17:14:08 +0100, Kurt Hornik
<Kurt.Hornik@wu-wien.ac.at> wrote:

Peter Dalgaard writes:

Kurt Hornik <Kurt.Hornik@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