From Ken.Williams at windlogics.com  Thu Apr 12 20:23:26 2012
From: Ken.Williams at windlogics.com (Ken Williams)
Date: Thu, 12 Apr 2012 13:23:26 -0500
Subject: [Rd] [patch] giving library() a 'version' argument
In-Reply-To: <CBAC830A.2C48F%proebuck@mdanderson.org>
References: <21A5E1E970CD46459ECBE86D6CC4B28C667AA9BA@spexch01.WindLogics.local>
	<CBAC830A.2C48F%proebuck@mdanderson.org>
Message-ID: <21A5E1E970CD46459ECBE86D6CC4B28C667AAA70@spexch01.WindLogics.local>



> -----Original Message-----
> From: Roebuck,Paul L [mailto:proebuck at mdanderson.org]
> Sent: Thursday, April 12, 2012 1:03 PM
> To: R-devel
> Cc: Ken Williams
> Subject: Re: [Rd] [patch] giving library() a 'version' argument
>
> 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"))

I was about to write back & say "that's not correct, if '7.10' is installed, a string comparison will do the wrong thing."

But apparently it does the *right* thing, because 'numeric_version' class implements the comparison operator.

I'd still prefer to "Huffman-code it" to something shorter, to encourage people to use it, but I can see why others could consider it good enough.

I could contribute a doc patch to the 'numeric_version' man page to make it clearer what's available.  The 3 comparisons there happen to turn out the same way when done as a string comparison.

I also do still have a question about what packageVersion() does when a package is already loaded - does it go look for it again, or does it check the version of what's already loaded?  A doc patch could help here too.

 -Ken

CONFIDENTIALITY NOTICE: This e-mail message is for the s...{{dropped:7}}



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