On Mon, 15 Dec 2008, Martin Morgan wrote:
Prof Brian Ripley <rip...@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
problems/misconceptions.
(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.
But if they have a version requirement it is going unchecked.
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
instances).
(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,
Yes, if a recent enough version is not already installed.
but that the package depending on 1.1.7 would not install.
Only if it uses lazy loading. It might install but not load otherwise.
It would be a mistake to install a package with unsatisfied
dependencies.
That's a point of view: see (E). Others would argue that the bug is in
the BioC release procedures, in that packages with impossible dependencies
should never be released.
(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
working.
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, rip...@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
--
Brian D. Ripley, rip...@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
