[Bioc-devel] GenomicFeatures namespace warning

[Hahne, Florian]

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