Skip to content

[Bioc-devel] class name collision in cache: igvR and Gviz

7 messages · Paul Shannon, Hervé Pagès, Michael Lawrence

Original
Paul Shannon
# 
I just discovered a class name collision - AnnotationTrack, in Gviz and my new package igvR.   wish to get wise counsel before proceeding with a fix.  Here?s the error message:

   Found more than one class "AnnotationTrack" in cache; 
   using the first, from namespace ?igvR' Also defined by ?Gviz?

AnnotationTrack is an abstract base class in my new package igvR.  The concrete derived classes at present are

  DataFrameAnnotationTrack
  GRangesAnnotationTrack
  UCSCBedAnnotationTrack

It would be easy for me to rename AnnotationTrack to ?GenomeAnnotationTrack? or even ?igvAnnotationTrack?, thereby  avoiding the name clash.  

Reasonable?  Fix in both release and devel?

Thanks -

 - Paul
Hervé Pagès
# 
Hi Paul,

Luckily you caught this only 3 days after the release so renaming the
class now is probably ok and shouldn't be disruptive.

Cheers,
H.
On 05/04/2018 10:52 AM, Paul Shannon wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Michael Lawrence
    

    

      
      #
    

  


  

      
Do you have a reproducible example of this? It's probably a bug in the
methods package.

Thanks,
Michael

On Fri, May 4, 2018 at 10:52 AM, Paul Shannon <

        
paul.thurmond.shannon at gmail.com> wrote:

        

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    
2 days later

    

      
      

        


  

        

      Paul Shannon
    

    

      
      #
    

  


  

      
Hi Michael,

            

      
      
      
    

        
Sorry I did not get to this sooner.  Here are two symptoms of the cache class name collision:

   1) igvR::displayTrack, if called after motifbreakR::plotMB, fails (see error message below)
   2) plotMB, if called after igvR is loaded, reports the class name collision.

- Paul

library(SNPlocs.Hsapiens.dbSNP150.GRCh38)
library(BSgenome.Hsapiens.UCSC.hg38)
library(motifbreakR)

snp <- "rs12050029"

snps.gr <- snps.from.rsid(rsid = snp,
                          dbSNP=SNPlocs.Hsapiens.dbSNP150.GRCh38,
                          search.genome=BSgenome.Hsapiens.UCSC.hg38)


results <- motifbreakR(snpList = snps.gr, filterp = TRUE,
                       pwmList = query(MotifDb, "jaspar2018"),
                       threshold = 1e-4,
                       method = "ic",
                       bkg = c(A=0.25, C=0.25, G=0.25, T=0.25),
                       BPPARAM = BiocParallel::bpparam("SerialParam"))

plotMB(results = results, rsid = snp, effect = c("weak", "strong"))


library(igvR)
igv <- igvR()
setGenome(igv, "hg38")
snp.track <- GRangesAnnotationTrack("snp", snps.gr, color="red")
displayTrack(igv, snp.track)

   # this error is only seen if motifbreakR - and thus Gviz - have been loaded
   # otherwise, displayTrack works fine
   # Error in if (trackType == "variant" && source == "file" && fileFormat ==  :
   #  missing value where TRUE/FALSE

plotMB(results = results, rsid = snp, effect = c("weak", "strong"))

   # Found more than one class "AnnotationTrack" in cache; using the first, from namespace 'Gviz'
   # Also defined by 'igvR'
   # Found more than one class "AnnotationTrack" in cache; using the first, from namespace 'Gviz'
   # Also defined by 'igvR'
   # Found more than one class "AnnotationTrack" in cache; using the first, from namespace 'Gviz'
   # Also defined by 'igvR'
   # Found more than one class "AnnotationTrack" in cache; using the first, from namespace 'Gviz'
   # Also defined by 'igvR'
   # Found more than one class "AnnotationTrack" in cache; using the first, from namespace 'Gviz'
   # Also defined by 'igvR'
   # Found more than one class "AnnotationTrack" in cache; using the first, from namespace 'Gviz'
   # Also defined by 'igvR'

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Michael Lawrence
    

    

      
      #
    

  


  

      
Thanks Paul.

I've made improvements to the methods package so that there will no longer
be any messages about AnnotationTrack being duplicated, but I'll need to
work through some failures this is causing in tests.

The first issue is interesting though. Since Gviz defines an initialize()
for AnnotationTrack, dispatch ends up using that intsead of the default.
That method (incorrectly in my opinion) silently drops unrecognized
arguments in "..." so it is effectively a no-op. Ideally the method would
eventually call callNextMethod(). Not doing so makes assumptions about how
the parent object is initialized. It would also make this case work, just
by luck. This is one reason why defining initialize() methods is tricky and
should be avoided.

Unfortunately, the methods package will dispatch to a method, regardless of
the package of origin, unless there are methods with signatures containing
two or more classes of the same name.  This might be easy to fix but there
could be performance regressions. This problem will happen all the time if
there are initialize() methods around. You should be able to avoid this
just by defining your own initialize() method that just calls the next
method. Ideally though Gviz would just drop its one.

Michael

On Mon, May 7, 2018 at 11:14 AM, Paul Shannon <

        
paul.thurmond.shannon at gmail.com> wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Paul Shannon
    

    

      
      #
    

  


  

      
Hi Michael,

Thank you for this work and the explanation.  It?s good to know that my problem will feed back into improvements in the methods package.

I opted for a simpler workaround, for now, renaming my abstract class to avoid the collision.  

 - Paul

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Michael Lawrence
    

    

      
      #
    

  


  

      
I pushed a fix into R devel.

On Wed, May 9, 2018 at 8:56 AM, Paul Shannon <

        
paul.thurmond.shannon at gmail.com> wrote: