[Rd] [patch] giving library() a 'version' argument

[Roebuck,Paul L]

On 4/12/12 10:11 AM, Ken Williams wrote:

>> On 4/12/12 7:22 AM, Duncan Murdoch wrote:
> [SNIP]
> ...
> The main hats targeted here are really people (like me, of course) who are
> trying to "productionize" results, not so much people who are doing offline
> analysis.  In a production system
> 
>> But what if your script requires a particular
>> (perhaps obsolete) version of a package?  This change only puts a lower
>> bound on the version number, and version requirements can be more
>> elaborate than that.
> 
> Certainly true; this was meant as a first iteration, and support for the more
> elaborate requirements specifications could certainly be added.
> 
> The more elaborate specs actually illustrate the need for a runtime mechanism
> nicely - if code X (which may be a package, or a script, it doesn't matter)
> requires exactly version 3.14 of package B, and someone in the production team
> upgrades version 3.14 to version 3.78 because "it's faster" or "it's less
> buggy" or "we just like to have the latest version of everything all the
> time", then someone needs to be alerted to the problem.  One alternative
> solution would be to use a full-fledged package management system like RPM or
> Deb to track all the dependencies, but yikes, that doesn't sound fun.

I appreciate your contribution of both time and energy.

But I think the existing library() method is sufficient without
this modification. It's essentially syntactic sugar for:

library(MASS); stopifnot(packageVersion("MASS") >= "7.3"))

If your package requirements are that exacting, it would be far
simpler to just download all the specific versions to a single
directory and put that directory first in .libPaths().

Prayer never hurt either...

Our style here is to add sessionInfo() to the end of all scripts
and Sweave documents. As such we could reproduce exactly if
required. But I believe it would be impossible to track the
dependencies meaningfully across time.