Re: [Rd] RE: [R] debugging non-visible functions

From: Prof Brian Ripley <ripley_at_stats.ox.ac.uk>
Date: Thu 14 Oct 2004 - 01:17:40 EST


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

______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Thu Oct 14 01:22:35 2004

This archive was generated by hypermail 2.1.8 : Wed 03 Nov 2004 - 22:45:21 EST