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