I've made a small enhancement to R that would help developers better control
what versions of code we're using where. Basically, to load a package in R,
one currently does:
library(whateverPackage)
and with the enhancement, you can ensure that you're getting at least
version X of the package:
library(whateverPackage, version=3.14)
Reasons one might want this include:
* you know that in version X some bug was fixed
* you know that in version X some feature was added
* that's the first version you've actually tested it with & you
don't want to vouch for earlier versions without testing
* you develop on one machine & deploy on another machine you don't
control, and you want runtime checks that the sysadmin installed what they were
supposed to install
In general, I have an interest in helping R get better at various things that
would help it play in a "production environment", for various values
of that term. =)
The attached patch is made against revision 58980 of
https://svn.r-project.org/R/trunk . I think this is the first patch I've
submitted to the R core, so please let me know if anything's amiss, or of
course if there are reservations about the approach.
Thanks.
--
Ken Williams, Senior Research Scientist
WindLogics
http://windlogics.com
CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution of any kind is strictly
prohibited. If you are not the intended recipient, please contact the sender via
reply e-mail and destroy all copies of the original message. Thank you.
Apparently the patch file got eaten. Let me try again with a .txt extension. -Ken> -----Original Message----- > From: Ken Williams > Sent: Wednesday, April 11, 2012 10:28 AM > To: r-devel at r-project.org > Subject: [patch] giving library() a 'version' argument > > I've made a small enhancement to R that would help developers better > control what versions of code we're using where. > [...]CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of any kind is strictly prohibited. If you are not the intended recipient, please contact the sender via reply e-mail and destroy all copies of the original message. Thank you. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lib-version-patch.txt URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20120411/ac7ce0d7/attachment.txt>
On 12-04-11 11:28 AM, Ken Williams wrote:> I've made a small enhancement to R that would help developers better control what versions of code we're using where. Basically, to load a package in R, one currently does: > > library(whateverPackage) > > and with the enhancement, you can ensure that you're getting at least version X of the package: > > library(whateverPackage, version=3.14) > > Reasons one might want this include: > > * you know that in version X some bug was fixed > * you know that in version X some feature was added > * that's the first version you've actually tested it with& you don't want to vouch for earlier versions without testing > * you develop on one machine& deploy on another machine you don't control, and you want runtime checks that the sysadmin installed what they were supposed to installI don't really see the need for this. Packages already have a scheme for requiring a particular version of a package, so this would only be useful in scripts run outside of packages. 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. I think my advice would be: 1. Put your code in a package, and use the version specifications there. 2. If you must write it in a script, then put a version test at the top, using packageVersion(). Duncan Murdoch> > In general, I have an interest in helping R get better at various things that would help it play in a "production environment", for various values of that term. =) > > The attached patch is made against revision 58980 of https://svn.r-project.org/R/trunk . I think this is the first patch I've submitted to the R core, so please let me know if anything's amiss, or of course if there are reservations about the approach. > > Thanks. > > -- > Ken Williams, Senior Research Scientist > WindLogics > http://windlogics.com > > > > CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of any kind is strictly prohibited. If you are not the intended recipient, please contact the sender via reply e-mail and destroy all copies of the original message. Thank you. > > > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
On 4/12/12 1:56 PM, "Ken Williams" <Ken.Williams at windlogics.com> wrote:> On April 12, 2012 1:48 PM, Paul Roebuck wrote: > >> Not sure I follow you here. The packageVersion() method is essentially a >> shortcut to packageDescription("MyPackage")$Version. I generally avoid >> doing package upgrades in my scripts so the loaded package IS the installed >> package (even when playing .libPaths() tricks). > > The scenario is: > > library(PackageX) # Quietly loads version 1 of PackageY > > # Try to load a specific version of PackageY > .libPaths('directory/containing/PackageY/version-2') > library(PackageY) # actually does nothing, since it's already loaded > stopifnot(packageVersion('PackageY') >= 2) # ?? > > > The intention of the stopifnot() expression is to make sure version 2 is > loaded. > > If packageVersion() goes & looks for PackageY in .libPaths() even when the > package is already loaded, it will provide the wrong answer - because it will > find version 2, but version 1 is what's loaded. However, if packageVersion() > checks the version of what's already loaded, then it would do the right thing > here. > > I don't think the docs for packageDescription() clarify what happens in this > case, but I could be missing it.If you're going to "play" with .libPaths() like that, it should be done prior to ANY libraries being loaded. Going about the style you do below, you'd need to parse sessionInfo() instead. packageVersion() as well as packageDescription() give you the information based on the first package in the path with the same name. If you dynamically change the path, the returned information could be different...