On Wed, 13 Oct 2004, Duncan Temple Lang wrote:
> Prof Brian Ripley wrote:
> > On Wed, 13 Oct 2004, Liaw, Andy wrote:
> >
> >
> > > On a slightly different topic: In R-2.0.0, packages with
NAMESPACE no
> > > longer need to use the package= argument in .C/.Fortran. Does
that mean if
> > > I remove those arguments, I should put R version >= 2.0.0 in
the Depend
> > > field of the DESCRIPTION?
> >
> > I think you should not remove the PACKAGE= (sic) arguments. There has
> > been little (none I have seen) discussion of that change, and Duncan
TL
> > will be able to elucidate. But the reason given in NEWS to omit them
> > relates to loading more than one versioned install of a package at
once,
> > something we were told originally by Robert G was not intended to be
> > allowed (and that is assumed in quite a few places in the code --
there is
> > no way to have imports from a version of a namespace, for example --
and
> > indeed importing from versioned install of namespaces did not work in
> > 2.0.0). Duncan?
>
>
> The reason in the NEWS file is exactly the motivation.
> It is for cases where one explicilty loads a package (A) via the library()
function,
> and a different version of that package is imported indirectly
> when loading another package via a dependency on an explicit
> version of A. And this is also the case when two packages (B and C)
> require different versions of the original package.
> A less pressing but useful use example is when one wants to compare
> results from different versions as one develops new releases.
> And similarly for reproducible research, we often need explicit
> versions of packages within a larger context of an existing R session.
> There are easy work arounds for some of these, but they are cumbersome.
The question is: does allowing simultaneous loading of versions actually
help solve these problems?
> I don't recall the exact details of Robert's original
> statements on this topic. As with many features
> introduced in R, the initial work (e.g. on namespaces) is not entirely
functional
> for all advanced, less-used aspects of other features being introduced.
> So we will have to allow a NAMESPACE to import from
> a particular version as things evolve. It is an issue,
> but I don't think we want to prohibit having
> different versions of a package loaded concurrently.
> Using a namespace provides a convenient way to find
> the associated DLL. We can also explicitly identify
Thanks for the clarification. Some of us were not aware that this was a
design goal, and it will be good to bear it in mind.
HOWEVER, I don't see we have any feasible solution without namespaces,
since whichever version is loaded last wins in the usual scoping rules.
If B requires A version 1 and C requires A version 2 and they are loaded
in that order the search path will be
C A_2 B A_1 (using Depends) or A_2 C A_1 B (using require)
and code in B will find objects from A_2 if they are in there. Without
versioned namespace imports I don't see how this helps: am I missing
something? (In R<=2.0.0 if you have a namespace in A you can't import
from it, at least in any way compatible with non-versioned installs.)
--
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
