There seems to be a widespread assumption that the way for package foo to
require package bar is via `require(bar)'. It isn't!
That returns a logical which is in the vast majority of cases unchecked.
So if the package is really required, the code will fail without a warning
if the package is unavailable. You may as well call library() and let it
do the checking. (In a few cases you can safely assume that the package
is present, e.g. nnet can require(MASS) since they are installed
together.)
I find it confusing if require(bar, quietly=TRUE) is used with no message.
If you are going to change the search path, please let the end user know
you have done so. I've had nasty surprises more than once from this by
getting datasets from packages I did not ask to be there.
Another point: please do not call code with side effects like require,
library or options at the top level in foo/R/foo, but do so within
.First.lib. This becomes important if the code is dumped or put in a
database.
Brian D. Ripley, ripley@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
On 21 Feb 2003 at 18:06, ripley@stats.ox.ac.uk wrote:
The problem which surprised Brian Ripley (the search list being
changed by a package without the package giving information)
occurs also with recommended packages:
(This is R1.6.2)
[1] ".GlobalEnv" "package:mva" "package:nlme"
"package:nls"
[5] "package:lattice" "package:grid" "package:ctest" "Autoloads"
[9] "package:base"
So nlme loads mva without a warning. This did'nt happen before
R1.6.0, I beleave.
On this theme, I have another question. I have a package
which needs another package (SuppDists) for only one
function. I do require() within that function only. Is that OK,
or should it be done within .First.lib ?
Kjetil Halvorsen
There seems to be a widespread assumption that the way for package foo to
require package bar is via `require(bar)'. It isn't!
That returns a logical which is in the vast majority of cases unchecked.
So if the package is really required, the code will fail without a warning
if the package is unavailable. You may as well call library() and let it
do the checking. (In a few cases you can safely assume that the package
is present, e.g. nnet can require(MASS) since they are installed
together.)
I find it confusing if require(bar, quietly=TRUE) is used with no message.
If you are going to change the search path, please let the end user know
you have done so. I've had nasty surprises more than once from this by
getting datasets from packages I did not ask to be there.
Another point: please do not call code with side effects like require,
library or options at the top level in foo/R/foo, but do so within
.First.lib. This becomes important if the code is dumped or put in a
database.
--
Brian D. Ripley, ripley@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
On Sat, 22 Feb 2003, kjetil brinchmann halvorsen wrote:
On this theme, I have another question. I have a package
which needs another package (SuppDists) for only one
function. I do require() within that function only. Is that OK,
or should it be done within .First.lib ?
Yes, that's fine. I should have stressed *at the top level* below.
In one scenario we have been experimenting with the objects in a package
are dumped to a database, and then loading the package makes the objects
available as promises and no longer executes the original package code.
Another scenario is to install with --save.
Another point: please do not call code with side effects like require,
library or options at the top level in foo/R/foo, but do so within
.First.lib. This becomes important if the code is dumped or put in a
database.
Brian D. Ripley, ripley@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
mva and grid has been loaded without any warning. Everybody knows
lattice requires grid, but why mva?
As far as I recall it is for the dist() function, which gets used in
some spatial/longitudinal models.
More precisely, it autoloads dist from mva, so you get mva if and only
if you use a function that uses it, and it seems that is corSpatial.
lattice autoloads loess and loess.smooth from modreg.
I don't like autoloads for this reason: they change the search path
without warning. Hopefully by 1.8.0 we will have better mechanisms
(import from namespaces, on-demand loading of objects from databases
which allows all the base and recommended packages to be attached with
negligible penalty).
Brian D. Ripley, ripley@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595