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.mich...@gene.com>
Sent: 13 October 2014 21:52
To: Dan Tenenbaum
Cc: Martin, Tiphaine; bioc-devel@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 
<dtene...@fhcrc.org<mailto:dtene...@fhcrc.org>> wrote:


----- Original Message -----
From: "Tiphaine Martin" 
<tiphaine.mar...@kcl.ac.uk<mailto:tiphaine.mar...@kcl.ac.uk>>
To: bioc-devel@r-project.org<mailto:bioc-devel@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.mar...@kcl.ac.uk<mailto:tiphaine.mar...@kcl.ac.uk>
Fax: +44 (0) 207 188 6761<tel:%2B44%20%280%29%20207%20188%206761>

       [[alternative HTML version deleted]]

_______________________________________________
Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


_______________________________________________
Bioc-devel@r-project.org<mailto:Bioc-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


        [[alternative HTML version deleted]]

_______________________________________________
Bioc-devel@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: hpa...@fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Reply via email to