Skip to content

[Bioc-devel] ggbio 1.13.11 fails to load due to namespace change in IRanges

4 messages · Leonardo Collado Torres, Martin Morgan, Michael Lawrence +1 more

Original
Leonardo Collado Torres
# 
Hi Tengfei and BioC-devel,

ggbio 1.13.11 fails to load due to recent changes in IRanges'
namespace as shown further below. Basically, some of IRanges previous
code now lives in S4Vectors.

On a recent thread Herv? exposed his view on specific imports versus
importing the whole package (see
https://stat.ethz.ch/pipermail/bioc-devel/2014-July/005943.html and
Stephanie's reply
https://stat.ethz.ch/pipermail/bioc-devel/2014-July/005948.html ).

I have been using specific imports because I thought it was the best
practice and that it would also help me learn more about what are the
functions/methods I'm relying on exactly. But as Herv? exposed, using
specific imports involves a lot of maintenance overhead. That is why,
in general I'll try to use general imports now.

Cheers,
Leo
Loading required package: BiocGenerics
Loading required package: parallel

Attaching package: ?BiocGenerics?

The following objects are masked from ?package:parallel?:

    clusterApply, clusterApplyLB, clusterCall, clusterEvalQ,
clusterExport, clusterMap, parApply, parCapply, parLapply,
    parLapplyLB, parRapply, parSapply, parSapplyLB

The following object is masked from ?package:stats?:

    xtabs

The following objects are masked from ?package:base?:

    anyDuplicated, append, as.data.frame, as.vector, cbind, colnames,
do.call, duplicated, eval, evalq, Filter, Find, get,
    intersect, is.unsorted, lapply, Map, mapply, match, mget, order,
paste, pmax, pmax.int, pmin, pmin.int, Position, rank,
    rbind, Reduce, rep.int, rownames, sapply, setdiff, sort, table,
tapply, union, unique, unlist

Loading required package: ggplot2
No methods found in "IRanges" for requests: Rle, substring, ifelse, as.factor
Error : object ?runValue? is not exported by 'namespace:IRanges'
Error: package or namespace load failed for ?ggbio?
2: stop(gettextf("package or namespace load failed for %s", sQuote(package)),
       call. = FALSE, domain = NA)
1: library(ggbio)
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

other attached packages:
[1] ggplot2_1.0.0       BiocGenerics_0.11.3

loaded via a namespace (and not attached):
 [1] AnnotationDbi_1.27.8     BatchJobs_1.3            BBmisc_1.7
         Biobase_2.25.0           BiocParallel_0.7.7
 [6] biomaRt_2.21.1           Biostrings_2.33.12       bitops_1.0-6
         brew_1.0-6               BSgenome_1.33.8
[11] checkmate_1.1            cluster_1.15.2           codetools_0.2-8
         colorspace_1.2-4         DBI_0.2-7
[16] dichromat_2.0-0          digest_0.6.4             fail_1.2
         foreach_1.4.2            Formula_1.1-2
[21] GenomeInfoDb_1.1.12      GenomicAlignments_1.1.21
GenomicFeatures_1.17.12  GenomicRanges_1.17.24    GGally_0.4.6
[26] grid_3.1.0               gridExtra_0.9.1          gtable_0.1.2
         Hmisc_3.14-4             IRanges_1.99.22
[31] iterators_1.0.7          lattice_0.20-29
latticeExtra_0.6-26      MASS_7.3-33              munsell_0.4.2
[36] plyr_1.8.1               proto_0.3-10
RColorBrewer_1.0-5       Rcpp_0.11.2              RCurl_1.95-4.1
[41] reshape_0.8.5            reshape2_1.4
Rsamtools_1.17.31        RSQLite_0.11.4           rtracklayer_1.25.13
[46] S4Vectors_0.1.2          scales_0.2.4             sendmailR_1.1-2
         splines_3.1.0            stats4_3.1.0
[51] stringr_0.6.2            survival_2.37-7          tools_3.1.0
         XML_3.98-1.1             XVector_0.5.7
[56] zlibbioc_1.11.1
[1] ?1.13.11?
Martin Morgan
#
On 07/16/2014 11:39 AM, Leonardo Collado Torres wrote:
That should really be a judgement call -- a nice tidy package might well import 
a very limited number of functions from a small number of packages, with the use 
of each function limited to specific and well-know locations, and with changes 
to the code being very considered -- I no longer need to import pkg::foo because 
I made a very specific change to the code. Indeed for less experienced 
developers it might be worth focusing on this as a kind of discipline -- write 
code that _is_ restricted in this way, doing a small number of tasks well rather 
than trying to do everything.

For the large and comprehensive packages Herve and others work on, this will 
certainly get tedious. For a more focused developer it is perhaps not so bad.

Martin

  
    

      
      
    

  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
Basically I agree with Stephanie, Martin, and Michael. I'm probably
a little biased when I'm advocating the "import all" approach.
I must also admit that I use a few selective imports in the
packages I maintain, exactly in the situations you guys describe,
that is, when I just need very few things from some other packages
(however these packages are base packages hence very stable).
Advantage: if I make a change in my package and don't need that
only function I import from the foo package anymore, then I
can remove that importFrom(foo, bar) line and hopefully will
also remember to remove foo from the Imports field, so I don't
depend on foo anymore.

So thanks for your more nuanced view on the "import all vs import
selectively" question.

@Leo: Try to update VariantAnnotation directly from svn. It was
updated in svn to reflect the changes in IRanges/S4Vectors but
didn't propagate because of other problems that prevent it from
propagating. Let me know if that still doesn't solve the problem.

Cheers,
H.

        
On 07/16/2014 12:38 PM, Michael Lawrence wrote: