[BioC] IRanges::unlist in package

Blanchette, Marco MAB at stowers.org
Wed Aug 14 06:45:33 CEST 2013


Thanks Herve, seems like this solves all my issues. 

Sent from my iPad

Marco Blanchette, Ph.D.
Genomic Scientist
Stowers Institute for Medical Research
1000 East 50th St.
Kansas City, MO 64110

Tel: 816-926-4071 
Cell: 816-726-8419 
Fax: 816-926-2018

On Aug 12, 2013, at 2:16 PM, "Hervé Pagès" <hpages at fhcrc.org> wrote:

> Hi,
> 
> On 08/12/2013 09:01 AM, Blanchette, Marco wrote:
>> Thanks James, yep, importMethodsFrom() did the trick for that function.
>> Now, I am stuck with a second function that also breaks when deployed from
>> a package but works just fine when located in the top level namespace. The
>> problem with this one is that it does not break per se but returns NA's,
>> which makes locating the faulty step quite difficult to find!
>> 
>> So, I have two questions:
>> 1) What's the best strategy to identify the packages that needs to have
>> their methods imported by the importMethodsFrom() function
>> 2) What is the best way to debug functions that behave differently when
>> loaded in a package vs on top level. Is there a way to "step in" a given
>> namespaceŠ
> 
> If your package operates on GRanges and GRangesList objects, I would
> highly recommend you put BiocGenerics, IRanges, and GenomicRanges in
> your Depends field, and that you also import them entirely in your
> NAMESPACE:
> 
> import(BiocGenerics)
> import(IRanges)
> import(GenomicRanges)
> 
> That will avoid you a lot of headaches (and also no need to fully
> qualify function names).
> 
> Cheers,
> H.
> 
>> 
>> Thanks
>> 
>> 
>> --  Marco Blanchette, Ph.D.
>> Stowers Institute for Medical Research
>> 1000 East 50th Street
>> Kansas City MO 64110
>> www.stowers.org
>> 
>> 
>> 
>> 
>> 
>> 
>> On 8/7/13 4:09 PM, "James W. MacDonald" <jmacdon at uw.edu> wrote:
>> 
>>> Hi Marco,
>>> 
>>> On 8/7/2013 4:51 PM, Blanchette, Marco wrote:
>>>> Dear all,
>>>> 
>>>> First, sorry for the double posting on the r-help and bioC, my mistakeŠ
>>>> Never meant to send it to the r-help list as it is a bioC question. So
>>>> here it isŠ
>>>> 
>>>> I am writing a package with some of my favorite custom functions so
>>>> that I can share them with others. I do not have a lot of experience
>>>> building these packages and I apologize if this is a trivial question.
>>>> 
>>>> The issue I am having is with the generic function unlist used to
>>>> unlist GRangesList object (unlist(GRL) from the IRanges package)
>>>> 
>>>> I have a function A in myPkg calling function B (myPkg::A{myPkg::B;
>>>> Š}), which is in the same package and call the unlist function of a
>>>> GRangesList object (myPkg::B{ unlist(GRL); Š }). For some reason, if I
>>>> have the two function on the top level namespace, everything works, but
>>>> when loaded from a package (library(myPkg); A(GRL)) it breaks at the
>>>> unlist() step. However, if I fully qualify the unlist function in myPkgB
>>>> (myPkg::B{IRanges::unlist(GRL); Š} ), then calling A(GRL) after loading
>>>> the myPkg library works.
>>>> 
>>>> So, are we expected to always fully qualify the unlist() function?
>>>> (i.e. Calling it with it's package name myPkg::B{ IRanges::unlist(GRL) }
>>>> ). I have been trying all strategy of Depends: and Imports: in my
>>>> DESCRIPTION file and nothing works unless I fully qualify this function.
>>> 
>>> I don't think you want to depend on IRanges if you only use this one
>>> function. Instead, you should be adding IRanges to the Imports list in
>>> your DEPENDS file, and using a NAMESPACE file that includes
>>> 
>>> importMethodsFrom(IRanges, unlist)
>>> 
>>> See
>>> 
>>> http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Namespaces-wit
>>> h-S4-classes-and-methods
>>> 
>>> for more information.
>>> 
>>> Best,
>>> 
>>> Jim
>>> 
>>> 
>>>> 
>>>> What is the best practice? I tried using only Imports: as suggested by
>>>> Chambers but it breaks. Using Depends does not help.
>>>> Am I having clashing namespace? Here is my Depends: (or Imports:) line:
>>>> Depends: Rsamtools, GenomicFeatures, parallel, rtracklayer, edgeR
>>>> 
>>>> Am I simply missing something?
>>>> 
>>>> Thanks
>>>> 
>>>> --  Marco Blanchette, Ph.D.
>>>> Stowers Institute for Medical Research
>>>> 1000 East 50th Street
>>>> Kansas City MO 64110
>>>> www.stowers.org
>>>> 
>>>> 
>>>>    [[alternative HTML version deleted]]
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>>> University of Washington
>>> Environmental and Occupational Health Sciences
>>> 4225 Roosevelt Way NE, # 100
>>> Seattle WA 98105-6099
>> 
>> _______________________________________________
>> 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
> 
> -- 
> Hervé Pagès
> 
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
> 
> E-mail: hpages at fhcrc.org
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319



More information about the Bioconductor mailing list