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

[Kurt Hornik]

>>>>> 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