[BioC] Library installation: odd error

Fri Jul 15 20:47:34 CEST 2011

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

>
> Thanks for the help!
>
> MJB
>
> _______________________________________________
> Bioconductor mailing list
> Bioconductor at r-project.org
> https://stat.ethz.ch/mailman/listinfo/bioconductor
> Search the archives:
> http://news.gmane.org/gmane.science.biology.informatics.conductor

-- 
James W. MacDonald, M.S.
Biostatistician
Douglas Lab
University of Michigan
Department of Human Genetics
5912 Buhl
1241 E. Catherine St.
Ann Arbor MI 48109-5618
734-615-7826
**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues 