GenomicRanges object no longer viewable
1
0
Entering edit mode
Chris Seidel ▴ 80
@chris-seidel-5840
Last seen 2.8 years ago
United States

While working with GenomicRanges objects, I constantly inspect them to make sense of things, but suddenly find I get errors when trying to view them:

gr <- GRanges(ranges=IRanges(start=c(100, 200), end=c(199, 299)), 
               seqnames=c("chr2", "chr3"),
               strand=c("+", "-"))
gr

gives an error of:

GRanges object with 2 ranges and 0 metadata columns: Error in getListElement(x, i, ...) : IRanges objects don't support [[, as.list(), lapply(), or unlist() at the moment

Subsetting doesn't work either (gr[1] fails). However, I can convert them to a dataframe for viewing:

as.data.frame(gr)
  seqnames start end width strand
1     chr2   100 199   100      +
2     chr3   200 299   100      -

but that's fairly awkward. The latest documentation indicates that simply calling the object name should list a few lines of the object. What is the current proper way to inspect the object? Should I interpret the "at the moment" part of the error message quite literally? i.e. things will return to normal at any moment? Please help.

sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS:   /n/apps/CentOS7/install/r-3.6.1/lib64/R/lib/libRblas.so
LAPACK: /n/apps/CentOS7/install/r-3.6.1/lib64/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8       
 [4] LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C              
[10] LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] parallel  stats4    stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] GenomicRanges_1.38.0 GenomeInfoDb_1.22.0  IRanges_2.20.0       S4Vectors_0.24.4    
[5] BiocGenerics_0.32.0  RColorBrewer_1.1-2  

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.4.6           digest_0.6.22          bitops_1.0-6          
 [4] evaluate_0.14          zlibbioc_1.32.0        rlang_0.4.1           
 [7] XVector_0.26.0         rmarkdown_1.16         tools_3.6.1           
[10] RCurl_1.95-4.12        xfun_0.10              yaml_2.2.0            
[13] compiler_3.6.1         htmltools_0.4.0        knitr_1.25            
[16] GenomeInfoDbData_1.2.2
GenomicRanges • 1.5k views
ADD COMMENT
0
Entering edit mode
@martin-morgan-1513
Last seen 6 weeks ago
United States

This seems like a package version mis-match; does BiocManager::valid() provide any hints?

ADD COMMENT
0
Entering edit mode

Martin,

Do you advise as good admin practice in managing a largish site-wide R library that whenever we install a new library (e.g. at end-user request) we take all available upgrades to other packages at that time? e.g. BiocManager::install('newLibrary',update=TRUE,ask=FALSE)

Chris & I are users of an installation which now has 686 'out-of-date' packages. My (perhaps old) understanding is that they are generally tolerated as long as they are 'consistent' with the version of Bioconductor. BTW, I used to admin our site R lib installation but no longer do, so may have fallen somewhat out of touch with subtleties and best practices for managing a largish shared installation.

Thanks for your advice. ~ Malcolm

Chris,

I took a quick look at what was added to our site-wide installation most recently, since this cropped up on Friday, and noticed updated versions of S4Vectors and BiocGenerics, along with a few others in our ../r-3.6.1/lib64/R/library:

Seeing then that IRanges is among the 688 reported as "out of date",

> v<-BiocManager::valid() 
>v$out_of_date
...
Package                     LibPath                                           Installed      Built   ReposVer       Repository                                                  
IRanges                   "IRanges"                   "/n/apps/CentOS7/install/r-3.6.1/lib64/R/library" "2.20.0"       "3.6.1" "2.20.2"       "https://bioconductor.org/packages/3.10/bioc/src/contrib"           
...

I did a

BiocManager::install('IRanges',update=FALSE)

into my home ~/R libraries which resolved the issue for me personally (Chris' example of the problem now works).

This should work for you as a short-term fix.

Especially if Martin agrees, the longer-term fix is to ask our admins to adopt the practice of updating all packages whenever any library is installed or updated. (This had been my practice when I pulled the strings, FWIW).

ADD REPLY
0
Entering edit mode

I think what has happened is that .libPaths() points to a location originally populated with R-3.6.x / Bioc 3.10 (for example) and now used by R-4.0.x / Bioc 3.11. The ~700 out-of-date packages were probably installed under a previous Bioc version; I doubt that more than several 10's of 'release' packages are updated. I would instead recommend a 'one library, one Bioc version' policy, where each version of Bioconductor has it's own library.

If I were managing a shared installation, I think I would keep it current via a daily cron job or similar, rather than 'on request'. I'd make sure that the policy was as public as possible, and would provide users desiring more complete reproducibility with some mechanism to 'snapshot' a particular collection of packages.

I wrote a short (probably buggy) script that suggests that about 249 Bioconductor packages were updated during the 3.10 release cycle, so ~700 packages out-of-date probably represents either multiple releases, or a significant number of CRAN dependencies that are also installed / have been updated.

ADD REPLY
0
Entering edit mode

I expect you are correct.

Thanks for your thoughts on our situation and appropriate practices. I agree with your emphasis on broadly and publically advertising the policy, and its results, to the user base.

I will take your suggestions up with our admins.

Regards...

ADD REPLY
0
Entering edit mode

I expect you are correct.

Thanks for your thoughts on our situation and appropriate practices. I agree with your emphasis on broadly and publically advertising the policy, and its results, to the user base.

I will take your suggestions up with our admins.

Regards...

ADD REPLY

Login before adding your answer.

Traffic: 996 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6