[BioC] Library installation: odd error

[Michael Bauer]

On 7/15/2011 2:47 PM, James W. MacDonald wrote:
> Hi Michael,
>
> On 7/15/2011 11:58 AM, Michael Bauer wrote:
>> On 7/12/2011 9:05 PM, Steve Lianoglou wrote:
>>> On Tue, Jul 12, 2011 at 6:21 PM, Michael Bauer<mjbauer at eecs.tufts.edu>
>>> wrote:
>>>> On 7/12/2011 4:06 PM, Steve Lianoglou wrote:
>>>>> Hi Michael,
>>>>>
>>>>> On Tue, Jul 12, 2011 at 3:47 PM, Michael 
>>>>> Bauer<mjbauer at eecs.tufts.edu>
>>>>> wrote:
>>>>>> I am a system administrator at a site with several R users. In
>>>>>> response
>>>>>> to
>>>>>> a previous set of questions, we were encouraged to have individual
>>>>>> users
>>>>>> set
>>>>>> up R library directories in their home directories and use the R
>>>>>> environment
>>>>>> variables to direct R to put auto-installed libraries there.
>>>>>>
>>>>>> However, we've run across one consistent problem: the library that
>>>>>> prompted
>>>>>> this whole string will not install on Linux. (It installs just fine
>>>>>> in R
>>>>>> on
>>>>>> Windows.) When presented with a writable library directory to 
>>>>>> install
>>>>>> into,
>>>>>> it the installation invariably fails with the error:
>>>>>>
>>>>>> Error in ret[i, ]<- c(pkgs[i], lib, desc) :
>>>>>> number of items to replace is not a multiple of replacement length
>>>>> I'll cut here.
>>>>>
>>>>> This has happened to me recently. Any time I tried to install
>>>>> *anything* I would get this error.
>>>>>
>>>>> So, first question: is it only when you try to install a particular
>>>>> package that this happens, or are all package-installs now hosed?
>>>>>
>>>>> I'm going to assume that all package installs are not working.
>>>>>
>>>>> This error was happening to me because there is a package that is
>>>>> *already* installed in the system which is "corrupt". I had installed
>>>>> a library that "hand crafted" its own installation, and I guess the
>>>>> meta-data that R requires a package to have has changed over time
>>>>> causing this custom-installed-package to trip things up.
>>>>>
>>>>> The details of my situation and how I fixed it are here:
>>>>> http://thread.gmane.org/gmane.comp.ai.machine-learning.shogun/2020
>>>>>
>>>>> The details of your problem are likely different -- but maybe this
>>>>> will help you find the offending package (if one exists)?
>>>>>
>>>>> Is there some package that was installed in a non-traditional manner?
>>>>>
>>>>> If you compare the output of `installed.packages()`[*] between your
>>>>> linux and windows install, you can find which packages are installed
>>>>> on the linux machine and not the windows machine that might be 
>>>>> causing
>>>>> these problems.
>>>>>
>>>>> HTH,
>>>>>
>>>>> -steve
>>>>>
>>>>> [*] you probably want to use `installed.packages()[,1]` since the
>>>>> object returned from the function call is a matrix.
>>>> So far as I know, I'm the only one who would have altered our
>>>> system-wide
>>>> installation of R, and I've followed installation instructions on each
>>>> occasion. I'll check out the one that caused you havoc (sg) as we
>>>> also have
>>>> that one installed, but the datestamp on it is from 2009, and we've
>>>> successfully installed quite a bit since then.
>>> Heh .. that's pretty funny. I wonder if it's too late for me to go out
>>> and buy a lotto ticket tonight ...
>>>
>>>> That datestamp, on the other hand, makes me suspect that several of
>>>> our R
>>>> libraries are significantly out of date. As a simple check, I'm
>>>> building R
>>>> from scratch in an alternate directory and will see if it can handle
>>>> installs.
>>> Dollars to donuts it will.
>>>
>>>> One question: is there any R configuration directory that I should be
>>>> looking in for environment changes, or is everything handled through
>>>> environment variables in the appropriate shell configuration?
>>> The R shell script should handle most of that, so I guess you can peak
>>> through that to see what it's doing.
>>>
>>> Also, each user can have an .Rprofile file in their home directory
>>> (~/.Rprofile) that R will normally load so that the user can tweak
>>> his/her R environment as they please.
>>>
>>> Something else regarding what you mentioned about old timestamps on
>>> many of your libraries: that seems like a bad thing in general,
>>> especially since (if I remember correctly) you said you're running the
>>> latest version of R (2.13.x).
>>>
>>> R libraries that were build for one version of R shouldn't be copied
>>> over and used in new R versions.
>>>
>>> If I were you, and was looking for a quick fix, I'd:
>>>
>>> (1) move that sg package out of the way for now, ie. move the `sg`
>>> directory outside of your R's library directory (you can fix it later
>>> using the info from that posting to that shogun list I sent
>>> previously, once everything is back to normal).
>>>
>>> (2) Try to install a random package to make sure that the `sg` package
>>> was the one causing the problem. glmnet is always handy to have:
>>>
>>> R> install.packages('glmnet')
>>>
>>> It actually requires a FORTRAN compiler, so if that gives you
>>> problems, maybe you can try plyr
>>>
>>> R> install.packages('plyr')
>>>
>>> (3) Assuming (2) worked, now update your installed packages from
>>> within R as described on the bioconductor install page
>>> (http://www.bioconductor.org/install/) -- perhaps using the nuclear
>>> option:
>>>
>>> R> source("http://bioconductor.org/biocLite.R")
>>> R> pkgs<- rownames(installed.packages())
>>> R> biocLite(pkgs)
>>>
>>> Although I'm pretty sure the option listed before that on that install
>>> page would work all the same ...
>>>
>>> -steve
>>>
>>
>> As it turns out, yes, the old libraries were the obstruction. The new R
>> I built worked fine until I added either one of the old library
>> directories to R_LIBS. So now I have the joy of ripping out all the
>> existing R libraries and replacing them with ones that people still want
>> system-wide -- fortunately a far smaller set.
>
> It sounds like you are updating R and then just copying things into 
> the new R's library directory. This will always end in tears unless 
> you ensure that the packages all get updated (R and especially BioC 
> have a tightly linked version structure, so you don't want to 
> mix'n'match).
>
> You will have to download packages to update, so moving things isn't 
> usually worth it. If you just want to recreate what you had after a 
> new R install, you can fire up the old version and do
>
> dput(row.names(installed.packages(priority = "NA")))
>
> Then copy that character vector and go to the new version and do
>
> source("http://www.bioconductor.org/biocLite.R")
> biocLite(paste_the_vector_here)
>
> alternatively, you could move the library directory over, then
>
> source("http://www.bioconductor.org/biocLite.R")
> biocLite("Biobase")
> library(Biobase)
> z <- biocReposList()
> update.packages(repos = z, ask = FALSE)
>
> Best,
>
> Jim

This all started when the Linux autoupdater handed us a new R binary and 
standard libraries to replace our old one.  As it turns out, the new R 
doesn't like where we keep some important stuff, so I'm building the new 
R from source, which should at least prevent this from happening again.

Once I have the new R in place, my plan is to reinstall Bioconductor and 
other libraries from scratch.

Thanks for the warning!
MJB