[BioC] warning in lumi
Martin Morgan
mtmorgan at fhcrc.org
Fri Feb 24 14:33:28 CET 2012
On 02/24/2012 01:32 AM, Francesco Mancuso wrote:
> Hi!
> I think you already know. Now when requiring lumi instead of a warning,
> I have the following error:
>
> Error : objects ‘plot’, ‘summary’ are not exported by
> 'namespace:BiocGenerics'
Have you used updated BiocGenerics? The following might be useful
source("http://bioconductor.org/biocLite.R")
biocLite(character())
which will discover and ask if you want to update all packages. I should
have updated the version dependency in BiocGenerics. Also, there is a
warning
Warning message:
replacing previous import 'plot' when loading 'graphics'
that comes from the genoset package; this warning will be addressed
separately.
>
> Best,
> Francesco
>
> On 23/02/2012 14:43, Martin Morgan wrote:
>> On 02/23/2012 03:38 AM, Francesco Mancuso wrote:
>>> Martin,
>>> many thanks for the explanations!
>>> But still in the lumi version 2.7.3 the warning persist.
>>>
>>> Warning message:
>>> Functions for exporting methods must have been made generic, explicitly
>>> or implicitly; not true when loading ‘lumi’ for ‘summary’
>> Bioconductor builds its packages on a daily basis; wait until version
>> 2.7.4 is available, hopefully at 9:30am PST. Martin
>>
>>> Best,
>>> Francesco
>>>
>>> > sessionInfo()
>>> R Under development (unstable) (2012-02-22 r58461)
>>> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
>>>
>>> locale:
>>> [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
>>>
>>> attached base packages:
>>> [1] stats graphics grDevices utils datasets methods base
>>>
>>> other attached packages:
>>> [1] lumi_2.7.3 nleqslv_1.9.2 methylumi_2.1.13
>>> Biobase_2.15.3 BiocGenerics_0.1.4
>>>
>>> loaded via a namespace (and not attached):
>>> [1] affy_1.33.2 affyio_1.23.1 annotate_1.33.1
>>> AnnotationDbi_1.17.15 bigmemory_4.2.11 BiocInstaller_1.3.7
>>> Biostrings_2.23.6 BSgenome_1.23.2
>>> [9] DBI_0.2-5 DNAcopy_1.29.0 GenomicRanges_1.7.25
>>> genoset_1.4.15 grid_2.15.0 hdrcde_2.15
>>> IRanges_1.13.24 KernSmooth_2.23-7
>>> [17] lattice_0.20-0 MASS_7.3-17 Matrix_1.0-4
>>> mgcv_1.7-13 nlme_3.1-103 preprocessCore_1.17.1
>>> RSQLite_0.11.1 xtable_1.6-0
>>> [25] zlibbioc_1.1.1
>>>
>>>
>>> On 22/02/2012 21:39, Martin Morgan wrote:
>>>> On 02/22/2012 12:07 PM, Kevin R. Coombes wrote:
>>>>> I am now really confused. (This is, perhaps, not an unusual state.)
>>>>>
>>>>> I just checked the documentation in R2.14.1, which is still the current
>>>>> release. The three function "standardGeneric", "isGeneric" and
>>>>> "setGeneric" are still there. The example NAMESPACE information in page
>>>>> 36 of "Writing R Extensions" include the following lines taken from the
>>>>> "stats4" package:
>>>>>
>>>>> export(mle)
>>>>> importFrom("graphics", plot)
>>>>> importFrom("stats", optim, qchisq)
>>>>> ## For these, we define methods or (AIC, BIC, nobs) an implicit generic:
>>>>> importFrom("stats", AIC, BIC, coef, confint, logLik, nobs, profile,
>>>>> update, vcov)
>>>>> exportClasses(mle, profile.mle, summary.mle)
>>>>> ## All methods for imported generics:
>>>>> exportMethods(coef, confint, logLik, plot, profile, summary, show,
>>>>> update, vcov)
>>>>> ## implicit generics which do not have any methods here
>>>>> export(AIC, BIC, nobs)
>>>>>
>>>>> It also explicitly claims that "exporting methods on a generic in the
>>>>> namespace will also export the generic, and
>>>>> exporting a generic in the namespace will also export its methods".
>>>> These are both true statements.
>>>>
>>>> I would say that the next lines
>>>>
>>>> "If the generic function is not local to this package, either because it
>>>> was imported as a generic function or because the non-generic version
>>>> has been made generic solely to add S4 methods to it (as for functions
>>>> such as plot in the example above), it can be declared via either or
>>>> both of export or exportMethods"
>>>>
>>>> are no longer accurate, as evidenced by the warning message that started
>>>> this thread. I would also say that, if the remedy to the warning has
>>>> been to use setGeneric("plot"), then the next clause
>>>>
>>>> "but the latter is clearer (and is used in the stats4 example above)"
>>>>
>>>> would not reflect my opinion -- the generic is being exported, along
>>>> with its newly-adorned methods.
>>>>
>>>>> Also, even when I am using BioConductor, I am often also using
>>>>> non-BioConductor packages (that might create their own generic version
>>>>> of plot, because R core still only supplies S3 generics and not S4
>>>>> generics for everything -- or at least the obvious things).
>>>> yes, you might choose to import a non-BiocGenerics generic to add your
>>>> method to, or to create your own generic and export that, or use the
>>>> generic provided by BiocGenerics, all of these are possible and until
>>>> plot is made an S4 generic in R, all will introduce multiple versions of
>>>> the plot generic. Choosing to use BiocGenerics reduces conflicts with
>>>> other Bioconductor packages, without having any further deterimental
>>>> consequences for non-Bioc packages -- at least a partial if not complete
>>>> win, with no down-sides.
>>>>
>>>> The 'if(!isGeneric("plot"))' construct implies that you do not want to
>>>> rely on imports, but instead on the search path (because otherwise you
>>>> would know whether plot was a generic or not, without having to
>>>> determine that in your code). This opens up any number of possible
>>>> problems, for instance that the plot generic on the search path has been
>>>> defined with different default behaviors or to dispatch on different
>>>> arguments than the method that you'd like to introduce.
>>>>
>>>>> In what sense are "those days behind us"?
>>>> I meant the days of not having a name space.
>>>>
>>>> Martin
>>>>
>>>>> On 2/22/2012 1:43 PM, Martin Morgan wrote:
>>>>>> On 02/22/2012 11:18 AM, Kevin R. Coombes wrote:
>>>>>>> Is this problem avoided by an explicit call to setGeneric in the R code
>>>>>>> of the package, in the usual idiom:
>>>>>>>
>>>>>>> if (!isGeneric("plot"))
>>>>>>> setGeneric("plot", function(x, y, ...) standardGeneric("plot"))
>>>>>>>
>>>>>>> or is there something else going on here that I don't understand?
>>>>>> This idiom is problematic. The rules are that if the developer
>>>>>> promotes the function to a generic, then it needs to be documented
>>>>>> (fair enough, the generic is not the same as the original). But the
>>>>>> construct is conditional, so the documentation is only sometimes
>>>>>> required. Further, if the developer promotes the generic, then they
>>>>>> need to export the generic rather than the method, export(plot) rather
>>>>>> than exportMethods(plot). Again this would be conditional with the
>>>>>> above scenario.
>>>>>>
>>>>>> Also, the developer is defining a method in their name space, and the
>>>>>> developer has full control of the name space -- there is no need to
>>>>>> determine at run time whether 'plot' is a generic or not;
>>>>>> importFrom(graphics, plot) imports a non-generic, so the promotion
>>>>>> would be required. It might be that plot has been promoted to a
>>>>>> generic somewhere on the user search path, but relying on the user
>>>>>> search path is not appropriate for a package; problems arise when a
>>>>>> third package tries to import methods from an intermediate package
>>>>>> (gory details available on request).
>>>>>>
>>>>>> And finally, within Bioconductor, it makes sense to avoid name
>>>>>> collisions as much as possible. So if the function has been promoted
>>>>>> to a generic in BiocGenerics, then that is the preferred source for
>>>>>> import -- importFrom(BiocGenerics, plot).
>>>>>>
>>>>>> I think the conditional construct dates from pre-NAMESPACE days, when
>>>>>> one really didn't have a choice. Those days are behind us.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>> On 2/22/2012 12:18 PM, Martin Morgan wrote:
>>>>>>>> On 02/22/2012 09:16 AM, Martin Morgan wrote:
>>>>>>>>> On 02/22/2012 07:56 AM, Francesco Mancuso wrote:
>>>>>>>>>> Dear all,
>>>>>>>>>> I am the author of a CRAN package (HumMeth27QCReport) that
>>>>>>>>>> denpends on
>>>>>>>>>> lumi.
>>>>>>>>>> Every time I call the lumi package I obtain the following warning:
>>>>>>>>>>
>>>>>>>>>> "
>>>>>>>>>> Functions for exporting methods must have been made generic,
>>>>>>>>>> explicitly or implicitly; not true when loading ‘lumi’ for ‘summary’
>>>>>>>>>> "
>>>>>>>>>>
>>>>>>>>>> Since this error comes not only when I try to build ny package but
>>>>>>>>>> also
>>>>>>>>>> when I require lumi from normal R command line, I think this is a
>>>>>>>>>> problem in lumi package itself. Am I correct?
>>>>>>>>>> Is there the possibility to solve it?
>>>>>>>>> Hi Francesco -- we are addressing these warnings in a number of Bioc
>>>>>>>>> packages; this particular problem was fixed in the devel branch last
>>>>>>>>> night. Martin
>>>>>>>> Maybe to provide developers with a little insight on this --
>>>>>>>>
>>>>>>>> Previously, in a NAMESPACE file one might
>>>>>>>>
>>>>>>>> importFrom(graphics, plot)
>>>>>>>>
>>>>>>>> 'plot' is a standard R function in graphics. and then somewhere in the
>>>>>>>> package code say
>>>>>>>>
>>>>>>>> setMethod(plot, "MyClass", ...)
>>>>>>>>
>>>>>>>> This would implicitly promote 'plot' from a standard R function to an
>>>>>>>> S4 generic, and then associate a method for plotting instances of
>>>>>>>> MyClass. Common practice was to then add to the NAMESPACE
>>>>>>>>
>>>>>>>> exportMethods(plot)
>>>>>>>>
>>>>>>>> This now generates a warning (soon to be an error, if I understand
>>>>>>>> R-core's intentions), because the plot method is exported without a
>>>>>>>> generic on which to export it. The solution is to explicitly create a
>>>>>>>> generic for 'plot', and to export (and document) that, as well.
>>>>>>>>
>>>>>>>> Several functions, including plot, are 'promoted' in this way
>>>>>>>> independently in different packages. This means that there would be
>>>>>>>> many separate plot generics on which to hang methods and the user
>>>>>>>> would potentially have to resolve dispatch to the package --
>>>>>>>> lumi::plot(...). The BiocGenerics package has been developed to
>>>>>>>> provide a central location for generic definition, in hopes of
>>>>>>>> avoiding this conflict. The BiocGenerics package creates commonly used
>>>>>>>> generics, and these are made available to other packages. So the
>>>>>>>> changes to lumi are
>>>>>>>>
>>>>>>>> 1. Add Imports: BiocGenerics to the DESCRIPTION file
>>>>>>>> 2. Add importFrom(BiocGenerics, plot) to the NAMESPACE file
>>>>>>>> 3. Remove importFrom(graphics, plot) from the NAMESPACE file
>>>>>>>>
>>>>>>>> If the generic were not defined in BiocGenerics, the solution would be
>>>>>>>>
>>>>>>>> 0. Tell us (via the bioc-devel list) that foo should be in
>>>>>>>> BiocGenerics?
>>>>>>>> 1. Introduce an explicit generic with setGeneric...
>>>>>>>> 2. Perhaps provide an S3 version of the S4 method, see ?Methods
>>>>>>>> 3. Export and document the explicit generic
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>>> r62969 |mtmorgan at fhcrc.org | 2012-02-21 20:37:50 -0800 (Tue, 21 Feb
>>>>>>>>> 2012) | 6 lines
>>>>>>>>>
>>>>>>>>> code tidyup
>>>>>>>>>
>>>>>>>>> - avoid implicit plot, summary generic with BiocGenerics
>>>>>>>>> - avoid partial matching
>>>>>>>>> - remove empty documentation sections
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Many thanks,
>>>>>>>>>> Francesco
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> sessionInfo()
>>>>>>>>>> R Under development (unstable) (2012-01-30 r58238)
>>>>>>>>>> Platform: i386-apple-darwin9.8.0/i386 (32-bit)
>>>>>>>>>>
>>>>>>>>>> locale:
>>>>>>>>>> [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
>>>>>>>>>>
>>>>>>>>>> attached base packages:
>>>>>>>>>> [1] stats graphics grDevices utils datasets methods base
>>>>>>>>>>
>>>>>>>>>> other attached packages:
>>>>>>>>>> [1] lumi_2.7.2 nleqslv_1.9.2 methylumi_2.1.13
>>>>>>>>>> Biobase_2.15.3 BiocGenerics_0.1.4
>>>>>>>>>>
>>>>>>>>>> loaded via a namespace (and not attached):
>>>>>>>>>> [1] affy_1.33.2 affyio_1.23.1 annotate_1.33.1
>>>>>>>>>> AnnotationDbi_1.17.15 BiocInstaller_1.3.7 DBI_0.2-5
>>>>>>>>>> grid_2.15.0 hdrcde_2.15
>>>>>>>>>> [9] IRanges_1.13.20 KernSmooth_2.23-7 lattice_0.20-0
>>>>>>>>>> MASS_7.3-16 Matrix_1.0-3 mgcv_1.7-13
>>>>>>>>>> nlme_3.1-103 preprocessCore_1.17.1
>>>>>>>>>> [17] RSQLite_0.11.1 tools_2.15.0 xtable_1.6-0
>>>>>>>>>> zlibbioc_1.1.1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>> --
>>>
>>> *Francesco Mattia Mancuso*
>>> Bioinformatician
>>>
>>> - Bioinformatics Core Facility
>>> - Proteomics Core Facility
>>>
>>> CRG-Centre for Genomic Regulation (Room 439)
>>> C/ Dr. Aiguader, 88 (Edif. PRBB)
>>> 08003 Barcelona, Spain
>>>
>>> Mail:francesco.mancuso at crg.eu <mailto:francesco.mancuso at crg.eu>
>>> Phone: +34 933160202
>>> http://www.crg.es/bioinformatics_unit
>>
>> --
>> Computational Biology
>> Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
>>
>> Location: M1-B861
>> Telephone: 206 667-2793
>> .
>>
>
> --
>
> *Francesco Mattia Mancuso*
> Bioinformatician
>
> - Bioinformatics Core Facility
> - Proteomics Core Facility
>
> CRG-Centre for Genomic Regulation (Room 439)
> C/ Dr. Aiguader, 88 (Edif. PRBB)
> 08003 Barcelona, Spain
>
> Mail: francesco.mancuso at crg.eu <mailto:francesco.mancuso at crg.eu>
> Phone: +34 933160202
> http://www.crg.es/bioinformatics_unit
--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
Location: M1-B861
Telephone: 206 667-2793
More information about the Bioconductor
mailing list