>>>>> Robert Gentleman writes:
> Hi,
Two quick (late) comments:
> Prof Brian Ripley wrote:
>> 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.
>>
>> The version dependence will in a future release cause an update of XML
>> when rtracklayer is installed, if needed (and available).
>>
>>
> I think we need to have this functionality in both Imports and Depends,
> see my response to another point for why.
>> (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.
> I don't think that is true. There are cases where both Imports and Depends
> are reasonable. The purpose of importing is to ensure correct resolution of
> symbols in the internal functions of a package. I would do that in almost all
> cases. In some instances I want users to see functionality from another
> package
> - and I can then either a) (re)export those functions, or if there are lots of
> them, then b) just put the package also in Depends. Now, a) is a bit less
> useful than it could be since R CMD check gets annoyed about these re-exported
> functions (I don't think it should care, the man page exists and is findable).
>>
>>
>> (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).
> It may be worthwhile, but this is a less frequent use case and I
> would prioritize it lower than having that functionality in Imports.
I think it would be good to have this too, because (see below) often
Suggests are used for "conditional Depends".
>>
>>
>> (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).)
>>
> I suspect one needs = (basically as Gabor pointed out, some packages
> have issues).
It would be good to support all comparison ops, I think (including !=).
Not something to be doable right away, but it would be very good to
allow for alternatives in dependency specs so that one can say things
like
Depends: foo | bar
indicating that one needs foo or bar, and most likely that if neither is
there installing the first one should be attempted.
Best
-k
>>
>> (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).
>>
> thanks
> Robert
> --
> Robert Gentleman, PhD
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M2-B876
> PO Box 19024
> Seattle, Washington 98109-1024
> 206-667-7700
> rgent...@fhcrc.org
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
