IRanges::unlist in package
1
0
Entering edit mode
@marco-blanchette-5439
Last seen 9.5 years ago
United States/Kansas City/Stowers Insti…
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. 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]]
rtracklayer IRanges GenomicFeatures Rsamtools rtracklayer IRanges GenomicFeatures Rsamtools • 1.4k views
ADD COMMENT
0
Entering edit mode
@james-w-macdonald-5106
Last seen 2 days ago
United States
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-with-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
ADD COMMENT
0
Entering edit mode
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? 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 >
ADD REPLY
0
Entering edit mode
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
ADD REPLY
0
Entering edit mode
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
ADD REPLY

Login before adding your answer.

Traffic: 827 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