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, [EMAIL PROTECTED] 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 ______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
