[Bioc-devel] runnable examples for internal function ?

Martin, Tiphaine tiphaine.martin at kcl.ac.uk
Wed Oct 15 15:30:21 CEST 2014


Hi Herve,

Thank you for your email. very useful.
But I updated my NAMESPACE in order to list only functions that I want to export.
Even if I did that and if in addition, I keep different man files for functions that I do not want to export, I have this error message.
But if I removed them, I don't have error messages.
I kept different man files for functions that I do not want to export to help my colleagues. It seems that currently, it is not recommended in Bioconductor.

thank you for your help,

Tiphaine
________________________________________
From: Hervé Pagès <hpages at fhcrc.org>
Sent: 14 October 2014 03:02
To: Martin, Tiphaine; Michael Lawrence; Dan Tenenbaum
Cc: bioc-devel at r-project.org
Subject: Re: [Bioc-devel] runnable examples for internal function ?

Hi Tiphaine,

On 10/13/2014 04:31 PM, Martin, Tiphaine wrote:
> Hi,
>
>
> I wrote a list of functions used in my package called coMET. I decided with my colleagues to try to publish it in Bioconductor. Currently, it has not been yet submitted to bioconductor because I would like to be sure that it satisfies all your guidelines.
> A list of functions is useful only internally. I saw that there are two methods to remove the function from the package index and to disable some of their automated tests: the first method is to put a dot as first letter, the second method is to put the "internal" keyword (http://cran.r-project.org/web/packages/roxygen2/vignettes/rdkeywords.html).

That link is to the documentation of the roxygen2 package. Are you
using roxygen2 to develop your package? You didn't say so.
You say that "you saw that prefixing the function name with a dot
or putting the 'internal' keyword in the man page will 'remove the
function from the package index and disable some of its automated
tests'". I guess that's something you saw in the roxygen2 documentation
right? I don't use roxygene2 myself so I don't know what's the roxygen2
way to control what's exposed or not to the user. However I know many
BioC developers use it for their package so maybe they'll be able to
provide some good advice here.

Keep in mind that using a tool like roxygen2 adds an extra layer of
convenience when developing your package but, unfortunately, it doesn't
completely exempt you from learning and understanding some basic
concepts like NAMESPACE, man pages aliases, keywords, etc...
The ultimate reference for these things is still the "Writing R
Extensions" manual:

   http://cran.r-project.org/doc/manuals/r-release/R-exts.html

So, and FWIW, below I'll describe quickly how you need to proceed when
you don't use a fancy tool like roxygen2 to automatically generate
the NAMESPACE and man pages in your package:

1) The real true way to not expose a function to the user is to not
    export it. What one exports from a package is controlled via
    the NAMESPACE file. So first you need to learn about how to use
    the NAMESPACE file to control exactly what you want to expose to
    the user. See "Writing R Extensions" manual for the details.

2) Every symbol that is exported needs to be documented, that is, there
    must be a man page with an alias for this symbol. And of course
    opening the man page at the R prompt with ?<symbol> should display
    useful information about that symbol.
    'R CMD check' is the tool that will check that every exported
    symbol is documented. It will also perform many checks on the
    man pages to make sure that they are formatted properly.

3) As Dan said previously, any function that is exported also needs
    to have runnable examples and a \value section in its man page.
    Note that this is a Bioconductor requirement, 'R CMD check'
    doesn't check that. 'R CMD BiocCheck' is the tool that will
    perform this check and any other Bioconductor specific check.

> I decided to use the second method to reduce to rewrite now all my package.

Note that, for "plain package development" (i.e. without using a
a fancy tool like roxygen2), using the "internal" keyword in a man
page has no effect on whether the function is exported or not.

>
>
> When I run the new version of BiocCheck Version 1.1.18 with empty \value and \example sections for function with "internal" keyword , I have error message asking to add no-empty runnable examples.
>
> When I run the new version of BiocCheck Version 1.1.18 without \value and \example sections for function with "internal" keyword , I have error message asking to add non-empty \value sections.
>
> with BiocCheck, version 1.0.2, I had a message for functions with "internal" keyword such as "
> Checking exported objects have runnable examples...
> * CONSIDER: Adding runnable examples to the following man pages
> which document exported objects:"
>
> I would like to know if I made a mistake to use internal keyword for this type of functions. What do I need to do ?

These changes in the output of BiocCheck are due to changes in
BiocCheck itself. In particular, the check on \value section was
added recently, and the check on the runnable examples was changed
recently from RECOMMENDED to REQUIRED.

>
> Which sections are mandatory in manual file

Mandatory sections:

   \name{}
   \alias{}  # you can have more than 1 alias
   \title{}
   \description{}
   \usage{}
   \arguments{}
   \value{}
   \examples{}

Highly recommended sections:

   \seealso{}
   \details{}

> and for which function I need to do a manual file ?

Any function that is exported.

Hope this helps,
H.

>
>
> Regards,
> Tiphaine
>
>
> ________________________________
> From: Michael Lawrence <lawrence.michael at gene.com>
> Sent: 13 October 2014 21:52
> To: Dan Tenenbaum
> Cc: Martin, Tiphaine; bioc-devel at r-project.org
> Subject: Re: [Bioc-devel] runnable examples for internal function ?
>
> It would be nice to know the use case of the internal keyword here. I've use it to avoid listing functions in the index (RGtk2 has thousands of functions). But in general, it's not a good idea to be exporting things that are truly internal. Perhaps internal methods on exported generics, but even then, it's probably best to keep the aliases with the generic, or something.
>
>
> On Mon, Oct 13, 2014 at 1:33 PM, Dan Tenenbaum <dtenenba at fhcrc.org<mailto:dtenenba at fhcrc.org>> wrote:
>
>
> ----- Original Message -----
>> From: "Tiphaine Martin" <tiphaine.martin at kcl.ac.uk<mailto:tiphaine.martin at kcl.ac.uk>>
>> To: bioc-devel at r-project.org<mailto:bioc-devel at r-project.org>
>> Sent: Monday, October 13, 2014 1:29:08 PM
>> Subject: [Bioc-devel] runnable examples for internal function ?
>>
>> Hi,
>>
>>
>> I would like to know if I need to add a runnable example for each
>> function that has keyword either internal or not.
>>
>
> I don't know what you mean by this, but maybe I should.
>
>>
>> I ask that because with BiocCheck, version 1.0.2, I had a message for
>> function with keyword "internal" such as "
>>
>> Checking exported objects have runnable examples...
>>      * CONSIDER: Adding runnable examples to the following man pages
>>        which document exported objects:"
>>
>
> If the function is exported, it must have a runnable example.
>
>
>> and now, I have an error message with BiocCheck, version 1.1.18
>>
>> * Checking exported objects have runnable examples...
>> Error in if (line == "## No test: " || insideDontTest || line == "##
>> End(No test)") { :
>>    missing value where TRUE/FALSE needed
>> Calls: <Anonymous> ... checkExportsAreDocumented ->
>> doesManPageHaveRunnableExample -> removeDontTest
>> Execution halted
>>
>
> Can you file an issue at https://github.com/Bioconductor/BiocCheck/issues and include the name of the package?
> I will get to it as soon as I can.
>
> Dan
>
>
>>
>> Regards,
>>
>> Tiphaine
>>
>>
>>
>> ----------------------------
>> Tiphaine Martin
>> PhD Research Student | King's College
>> The Department of Twin Research & Genetic Epidemiology | Genetics &
>> Molecular Medicine Division
>> St Thomas' Hospital
>> 4th Floor, Block D, South Wing
>> SE1 7EH, London
>> United Kingdom
>>
>> email : tiphaine.martin at kcl.ac.uk<mailto:tiphaine.martin at kcl.ac.uk>
>> Fax: +44 (0) 207 188 6761<tel:%2B44%20%280%29%20207%20188%206761>
>>
>>        [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
> _______________________________________________
> Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
>       [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

--
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



More information about the Bioc-devel mailing list