[Rd] install.packages and dependency version checking
mtmorgan at fhcrc.org
Mon Dec 15 19:05:54 CET 2008
Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
> I've started to implement checks for package versions on dependencies
> in install.packages(). However, this is revealing a number of
> (A) We do not check versions when loading namespaces, ahd the
> namespace registry does not contain version information. So that for
> example (rtracklayer)
> Depends: R (>= 2.7.0), Biobase, methods, RCurl
> Imports: XML (>= 1.98-0), IRanges, Biostrings
> will never check the version of namespace XML that is loaded, either
> already loaded or resulting from loading this package's namespace.
> For this to be operational we would need to extend the syntax of the
> imports() and importsFrom() directive in a NAMESPACE file to allow
> version restrictions. I am not sure this is worth doing, as an
> alternative is to put the imported package in Depends.
Without XML in Imports: references in the package name space to
functions in XML rely on the user not adjusting their search
path. Often XML may well be 'infrastructure' that the end-user has no
use for, and should not be contributing to the possibility of
unexpected name collisions by cluttering their search path.
> The version dependence will in a future release cause an update of XML
> when rtracklayer is installed, if needed (and available).
> (B) Things like (package stam)
> Depends: R (>= 2.7.0), GO.db (>= 2.1.3), Biobase (>= 1.99.5), pamr (>=
> 1.37.0), cluster (>= 1.11.10), annaffy (>= 1.11.5), methods (>=
> 2.7.0), utils (>= 2.7.0)
> are redundant: the versions of method and utils are always the same as
> that of R.
> And there is no point in having a package in both Depends: and
> Imports:, as Biostrings has.
Imports: (and imports() in NAMESPACE) gives the name space reliable
access to specific functions / classes; Depends: gives the user access
to (possibly a greater diversity of) functions.
> (C) There is no check on the version of a package suggested by
> Suggests:, unless the package itself provides one (and I found no
> (D) We can really only handle >= dependencies on package versions (but
> then I can see no other ops in use). install.packages() will find the
> latest version available on the repositories, and we possibly need to
> check version requirements on the same dependency many times. Given
> that BioC has a penchant for having version dependencies on
> unavailable versions (e.g. last week on IRanges (>= 1.1.7) with 1.1.4
> available), we may be able to satisfy the requirements of some
> packages and not others. (In that case the strategy used is to install
> the latest available version if the one installed does not suffice for
> those we can satisfy, and report the problem(s).)
To clarify, I guess you mean that IRanges 1.1.4 would be installed for
packages that specified, say, IRanges >= 1.1.0, but that the package
depending on 1.1.7 would not install. It would be a mistake to install
a package with unsatisfied dependencies.
> (E) One of the arguments that has been used to do this version
> checking at install time is to avoid installing packages that cannot
> work. It would be possible to extend the approach to do so, but I am
> going to leave that to those who advocated it.
> The net effect of the current changes will be that if there is a
> dependence that is already installed but a later version is available
> and will help satisfy a >= dependence, it will be added to the list of
> packages to be installed. As we have seen with Matrix this last week,
> that can have downsides in stopping previously functional packages
> This is work in progress: there is no way to write a test suite that
> will encapsulate all the possible scenarios so weneed to get
> experience until 2.9.0 is released. Please report any quirks to
> R-devel if they are completely reproducible (and preferably with the
> code change needed to fix them, since the chance of anyone else being
> able to reproduce them are fairly slim).
> Brian D. Ripley, ripley at 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 at r-project.org mailing list
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
More information about the R-devel