[Rd] install.packages and dependency version checking

[Prof Brian Ripley]

On Mon, 15 Dec 2008, Martin Morgan wrote:

> 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
>> 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,                  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

-- 
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