[Bioc-devel] Announcing newtest coverage shields
Hello Bioconductors, We're pleased to announce a new shield to join the ones we rolled out in May. The new shield measures test coverage of a package, as determined by Jim Hester's covr package. Coverage is a measure of the degree to which package code is tested by your unit tests (https://en.wikipedia.org/wiki/Code_coverage). If you don't know what unit tests are, read our guidelines at http://bioconductor.org/developers/how-to/unitTesting-guidelines/ . These shields are on all package landing pages for software packages in release and devel. An example shield can be seen at http://bioconductor.org/packages//Biobase/ It links to a detailed coverage report at https://codecov.io/ . If package coverage cannot be determined (shield value is 'unknown'), the shield links to a section of http://bioconductor.org/developers/how-to/unitTesting-guidelines/#coverage explaining why this might be. Note that the coverage calculation happens on our linux build machines only and is not run as part of the nightly builds, but it is run several times a week. Only packages whose code has changed since the last calculation are run through covr. We hope this shield motivates package developers to add unit tests (if they don't have them already) and improve their package's unit test coverage. Refer to the covr documentation (http://cran.r-project.org/web/packages/covr/README.html) for more information on how to do this. Questions and comments are welcome as always on the bioc-devel list. Thanks, Dan ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Announcing newtest coverage shields
On Wed, Jun 24, 2015 at 5:42 PM, Dan Tenenbaum dtene...@fredhutch.org wrote: Hello Bioconductors, We're pleased to announce a new shield to join the ones we rolled out in May. The new shield measures test coverage of a package, as determined by Jim Hester's covr package. Coverage is a measure of the degree to which package code is tested by your unit tests (https://en.wikipedia.org/wiki/Code_coverage). If you don't know what unit tests are, read our guidelines at http://bioconductor.org/developers/how-to/unitTesting-guidelines/ . These shields are on all package landing pages for software packages in release and devel. An example shield can be seen at http://bioconductor.org/packages//Biobase/ It links to a detailed coverage report at https://codecov.io/ . If package coverage cannot be determined (shield value is 'unknown'), the shield links to a section of http://bioconductor.org/developers/how-to/unitTesting-guidelines/#coverage explaining why this might be. Note that the coverage calculation happens on our linux build machines only and is not run as part of the nightly builds, but it is run several times a week. Only packages whose code has changed since the last calculation are run through covr. We hope this shield motivates package developers to add unit tests (if they don't have them already) and improve their package's unit test coverage. Refer to the covr documentation (http://cran.r-project.org/web/packages/covr/README.html) for more information on how to do this. Questions and comments are welcome as always on the bioc-devel list. [snare drums] ... hi-hat! Thank you very much for adding this. For folks who yet haven't looked into code coverage - it's extremely useful: * You get line-by-line coverage estimates for your R code, e.g. https://codecov.io/github/Bioconductor-mirror/DNAcopy/R/segment.R * Also for your native code, e.g. https://codecov.io/github/Bioconductor-mirror/DNAcopy/src/changepoints.f?ref=master * The line-to-line reports makes it very easy to design new tests. My experience from turning uncovered (red) code lines into covered (green) is that you are quite likely to discover a few more bugs along the way. I'd say it's one of the most efficient ways to find unknown bugs that I ever used. A useful rule of thumb is to always make sure that the code coverage never decreases whenever a new version is released. /Henrik Thanks, Dan ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] best practice: dependencies of dependencies / no visible global function definition
On 06/24/2015 10:42 AM, Michael Lawrence wrote:
In order for R to find those symbols reliably, you need to import
those functions into your NAMESPACE, and therefore you should ensure
yes
that the Biobase package is listed on the Depends line of your
DESCRIPTION. Your package directly depends on Biobase, so there's no
Hmm,
Imports: Biobase
and in the NAMESPACE
import(Biobase)
or selectively importFrom(Biobase, ...) would ensure that the symbols are always
available in your package and would eliminate the note (which should really be
stronger than that) about undefined symbols. Failing to import the symbols from
Biobase is actually closer to an error in your current package -- a package
Import'ing (not Depend'ing on) your package could invoke your function, but your
function would not see the Biobase symbols it uses. Also, without
import(Biobase) or importFrom(Biobase, ...) the user could define pData =
function(...) {}, or attach a package that defines a pData function, and this
would break your code.
Personally and more or less as a separate issue, I would Depends: Biobase (so
arriving at the same solution as Michael) to communicate to your users / fellow
developers that yes, they can expect to work with Biobase functionality when
using your package. I'd do this even if I received a NOTE: about too many
non-base packages is Depends:.
Martin
On Wed, Jun 24, 2015 at 10:36 AM, Ludwig Geistlinger
ludwig.geistlin...@bio.ifi.lmu.de wrote:
I'm surely not the first asking this question.
But as I did not find a clear answer to that (e.g. in the 'Writing R
extensions' manual or in the diverse posts on this), I risk asking it
again.
As an example:
I'm dealing a lot with ExpressionSets (from Biobase) and
GeneSet[Collection]s (from GSEABase) in my package and they are in-
outputs of my exported functions, so I want them to be available when my
package is loaded.
Thus, I would tend to put both, 'Biobase' and 'GSEABase', in the 'Depends'
field of my DESCRIPTION file and a corresponding 'import' directive in my
NAMESPACE file.
However, I do know that 'GSEABase' depends on 'Biobase' - so in order to
be not redundant and keeping the 'Depends' field as small as possible, I
could also remove 'Biobase' from my 'Depends'.
Now, everything still works fine (building, installing, and I still got
the ExpressionSets when loading my package), however R CMD CHECK now
*notes* on many occasions:
no visible global function definition for ‘pData’
no visible global function definition for ‘exprs’
no visible global function definition for ‘fData’
...
Ok, these are NOTES, but I assume they are there for a reason.
So, I wonder what a developer's best practice is on that - ignoring the
notes, adding all Biobase/ExpressionSet functionality via imports, or
indeed depending on both packages.
Best,
Ludwig
--
Dipl.-Bioinf. Ludwig Geistlinger
Lehr- und Forschungseinheit für Bioinformatik
Institut für Informatik
Ludwig-Maximilians-Universität München
Amalienstrasse 17, 2. Stock, Büro A201
80333 München
Tel.: 089-2180-4067
eMail: ludwig.geistlin...@bio.ifi.lmu.de
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] best practice: dependencies of dependencies / no visible global function definition
I'm surely not the first asking this question. But as I did not find a clear answer to that (e.g. in the 'Writing R extensions' manual or in the diverse posts on this), I risk asking it again. As an example: I'm dealing a lot with ExpressionSets (from Biobase) and GeneSet[Collection]s (from GSEABase) in my package and they are in- outputs of my exported functions, so I want them to be available when my package is loaded. Thus, I would tend to put both, 'Biobase' and 'GSEABase', in the 'Depends' field of my DESCRIPTION file and a corresponding 'import' directive in my NAMESPACE file. However, I do know that 'GSEABase' depends on 'Biobase' - so in order to be not redundant and keeping the 'Depends' field as small as possible, I could also remove 'Biobase' from my 'Depends'. Now, everything still works fine (building, installing, and I still got the ExpressionSets when loading my package), however R CMD CHECK now *notes* on many occasions: no visible global function definition for pData no visible global function definition for exprs no visible global function definition for fData ... Ok, these are NOTES, but I assume they are there for a reason. So, I wonder what a developer's best practice is on that - ignoring the notes, adding all Biobase/ExpressionSet functionality via imports, or indeed depending on both packages. Best, Ludwig -- Dipl.-Bioinf. Ludwig Geistlinger Lehr- und Forschungseinheit für Bioinformatik Institut für Informatik Ludwig-Maximilians-Universität München Amalienstrasse 17, 2. Stock, Büro A201 80333 München Tel.: 089-2180-4067 eMail: ludwig.geistlin...@bio.ifi.lmu.de ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] best practice: dependencies of dependencies / no visible global function definition
In order for R to find those symbols reliably, you need to import those functions into your NAMESPACE, and therefore you should ensure that the Biobase package is listed on the Depends line of your DESCRIPTION. Your package directly depends on Biobase, so there's no redundancy by having it listed in Depends. On Wed, Jun 24, 2015 at 10:36 AM, Ludwig Geistlinger ludwig.geistlin...@bio.ifi.lmu.de wrote: I'm surely not the first asking this question. But as I did not find a clear answer to that (e.g. in the 'Writing R extensions' manual or in the diverse posts on this), I risk asking it again. As an example: I'm dealing a lot with ExpressionSets (from Biobase) and GeneSet[Collection]s (from GSEABase) in my package and they are in- outputs of my exported functions, so I want them to be available when my package is loaded. Thus, I would tend to put both, 'Biobase' and 'GSEABase', in the 'Depends' field of my DESCRIPTION file and a corresponding 'import' directive in my NAMESPACE file. However, I do know that 'GSEABase' depends on 'Biobase' - so in order to be not redundant and keeping the 'Depends' field as small as possible, I could also remove 'Biobase' from my 'Depends'. Now, everything still works fine (building, installing, and I still got the ExpressionSets when loading my package), however R CMD CHECK now *notes* on many occasions: no visible global function definition for ‘pData’ no visible global function definition for ‘exprs’ no visible global function definition for ‘fData’ ... Ok, these are NOTES, but I assume they are there for a reason. So, I wonder what a developer's best practice is on that - ignoring the notes, adding all Biobase/ExpressionSet functionality via imports, or indeed depending on both packages. Best, Ludwig -- Dipl.-Bioinf. Ludwig Geistlinger Lehr- und Forschungseinheit für Bioinformatik Institut für Informatik Ludwig-Maximilians-Universität München Amalienstrasse 17, 2. Stock, Büro A201 80333 München Tel.: 089-2180-4067 eMail: ludwig.geistlin...@bio.ifi.lmu.de ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
