On 13/08/2018 9:08 AM, Eggleston, Barry wrote:
Hello,

I am working through my first submission and making good progress with the CRAN 
review system, but now I need to understand the best practice for dealing with 
helper functions.  I am building a package that only exports 12 functions for 
direct user access, but it has many helper functions not directly accessible to 
the user.  In my R code I am using roxygen2 to write my help pages.  I have 
written roxygen2 notes to create help pages for every function, but for all the 
helper functions I am using the keyword 'internal' so they don't show up in the 
index of help pages and available functions.  In future releases I may export 
these functions for direct access, but for now I want to keep them internal.  
Within each help page of these non-accessible helper functions, I have placed 
'#None' in the @examples section, since nobody will be able to call the 
functions directly.  In my submission review I was asked to give examples for 
these functions, because my package still has the .Rd files
 f
  or these helper functions in the submitted .tar.gz file.  How do I proper 
handle documentation of these helper functions?  Can I remove the roxygen2 
notes that create the .Rd files for these helper functions, so the package does 
not contain .Rd files for them?


This sounds like a bug in the review system. Marking them with \keyword{internal} is how you are supposed to mark internal-use functions. Most such help pages (e.g. ?layout.heights from the grid package) don't have examples.

If you got the message from a human being, you could just resubmit with a note pointing out that those pages are marked as internal. If it was from the automatic checks, it's probably best to try one of the workarounds that someone else suggested.

Duncan Murdoch
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Reply via email to