[Bioc-devel] GenomicFeatures namespace warning
Hi Martin, Thanks for the clarification. I guess my last point was that if a package depends on another package the assumption is that one uses more or less everything from that package. Otherwise one could import the bits and pieces one needs? That's unless it make sense to have additional functionality of another package available for downstream tasks for instance when a package return and object that is defined in another package, which I guess is the case with Granges and GenomicFeatures.
On 8/20/12 2:53 PM, "Martin Morgan" <mtmorgan at fhcrc.org> wrote:
On 08/20/2012 02:33 AM, Hahne, Florian wrote:
Hi Marc,I get a strange namespace warning in one of my packages which seem to originate from GenomicFeatures:** testing if installed package can be loaded Warning: No function found corresponding to methods exports from ?GenomicFeatures? for: ?seqnameStyle? The strange thing is that I am importing some methods and classes from your package, but never touch seqnameStyle: importClassesFrom(GenomicFeatures, "TranscriptDb") importMethodsFrom(GenomicFeatures, isActiveSeq, "isActiveSeq<-", exonsBy, transcriptsBy, transcripts) The generic is defined in GenomicRanges, and I am at a complete loss now why I am seeing this warning. I neither import nor explicitly call seqnameStyle from GenomicFeatures, and simply importing the generic from GenomicRanges in my package names pace doesn't seem to do the trick, either. I suspect that you are doing something funky in your package name space. You seem to export a method for seqnameStyle without ever importing the generic, and while your own package depends on GenomicRanges that will work when directly loading GenomicFeatures, but everybody who imports from it will not see it. To make a long story short: I think you need to add seqnameStyle to your importFrom(GenomicRanges) to fix that problem. As a more general remark (and maybe Martin can chime in here): If you depend on a package A shouldn't you also import the whole package name space into your own package B? Otherwise all those functions that are exported in A will not be available in anybody else's package C which imports from B. (B gets loaded but not attached, thus A does not get attached, thus nothing in A.namespace is available to C)
Hi Florian -- I think your analysis is correct, but also that B should just import what it needs from A. Likewise, C should import what it needs from B, and also import what it needs from A. Certainly it would be wrong if B's package code relied on a function A::foo that was only available because A was attached -- B should importFrom(A, foo). Martin
Cheers, Florian
-- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793