[R] how to get old packages to work on R 2.12.1

[Robert Baer]

Did you do:
update.packages(checkBuilt=TRUE)

Rob
--------------------------------------------------
From: "Joshua Wiley" <jwiley.psych at gmail.com>
Sent: Wednesday, January 19, 2011 11:43 AM
To: "Joseph Boyer" <joseph.g.boyer at gsk.com>
Cc: <r-help at r-project.org>
Subject: Re: [R] how to get old packages to work on R 2.12.1

> Dear Joe,
>
> On Wed, Jan 19, 2011 at 7:49 AM, Joseph Boyer <joseph.g.boyer at gsk.com> 
> wrote:
>> I just installed R 2.12.1, and when I went to run a few old programs with 
>> it, nothing worked.
>> I got a ton of error messages saying such and such package was built 
>> before R 2.10.0 and needed to be reinstalled.
>>
>> These were not just warning messages, but error messages that prevent the 
>> programs from running when
>> they were running just fine with R 2.10.1
>>
>> For some of those packages, such as deSolve, I can't find any recent 
>> versions to download to correct the problem.
>>
>> So my first question is, is there a way around this error that doesn't 
>> require actually installing recent versions of all those old packages?
>> I suppose I could just use R 2.10.1, but suppose at some point I want to 
>> use both an old package and a new package that was built
>> under R 2.12.1 in the same program? That has happened by the way. I 
>> wanted to use deSolve and yags. Since I don't have an old version of 
>> yags,
>> I had to install the current version on CRAN, and it won't work under 
>> 2.10.1.
>
> This is not an option for your current problem, but if backwards
> compatibility is important, keep backups.  I borrowed this idea from
> Debian which has stable and unstable versions.  The stable ones are
> "frozen"---no more updates are done (not 100% true, but that is the
> gist).  R is very well behaved about having multiple installs, so I
> typically install new versions in a new directory and then install all
> my packages again (I keep an R script for this).  Once I am satisfied
> that everything I want to do works in the latest and greatest version
> of R + updated packages, I can delete the old versions, otherwise, I
> just keep both.  Storage is available cheaply (< .05 USD per
> gigabyte), so unless you're installing all of CRAN, it should not cost
> much to keep duplicates.
>
>>
>> My second question is, if not, should the R developers reconsider their 
>> strategic decision to invalidate packages just because they were built
>> under early versions of R?
>
> I do not believe that packages are invalidated because of their
> version.  There are instances where old code no longer works, and some
> newer packages may also require more modern versions of packages
> because either the package maintainers know the older package versions
> do not work as they want, or they are unsure and unwilling to deal
> with the hassle.  In any case, everything I have seen suggests that
> the R core team is very aware of compatibility issues and does as much
> as possible to keep R core stable and compatible.  There have been
> quite a few discussions on the R-devel list about new features etc.
> that invariably include a discussion of what the ramifications of
> change would be and whether or not it is justified.
>
>>
>> I would be willing to bet that for many users, the improvements from R 
>> 2.10.1 to R 2.12.1 are minor compared with the hassle caused by the fact
>> that their old programs will no longer work.
>>
>> This especially complicates application development, where the R 
>> programmer is not the end user.
>> What developer is going to use R for his applications if he can't even be 
>> sure they will work under future versions?
>
> I think many would, do, and will.  Improvement and progress
> necessitate change (I suspect most developers are thrilled not to be
> stuck using paper tape in batch mode [and my sincerest condolences to
> those who still fondly remember and lament the loss]).  The R core
> team is very good about giving advance warning and providing R-devel
> before it is officially released which allows software developers to
> start working with the new code and updating their programs if
> necessary before the latest version of R is rolled out to general
> users.
>
> I know it is frustrating and a hassle when something that used to work
> stops (I currently work with Windows 7 x64, Windows XP x32, and Debian
> unstable---trying to keep all three up-to-date and working similarly
> keeps me on my toes and if half the things I've muttered under my
> breath about computers at 2am actually came to pass.....), but also
> consider that the R core team already freely volunteer their time and
> (vast) skill to provide us this wonderful software.  I do not think it
> is too much to ask that software developers and users be willing to
> put in some of their own time to update when there are changes and
> improvements to R that are, ultimately, benefiting us anyways.  If it
> is truly too much bother and hassle for minor improvements, it may be
> better to only upgrade R versions at major releases (1, 2, 3, etc.).
> My school seems to have taken this approach and still has 1.8.1, I
> think, loaded on their lab computers.
>
> My $.02 (or$.05)
>
> Sincerely,
>
> Josh
>
>
>>
>> Joe Boyer
>> Principal Statistician
>> GSK Department of Statistical Sciences
>> 8-275-3661
>> external: 610-787-3661
>>
>>
>>        [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-help at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide 
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>
>
> -- 
> Joshua Wiley
> Ph.D. Student, Health Psychology
> University of California, Los Angeles
> http://www.joshuawiley.com/
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>