Hi,
I am currently developing a package and the only issue I have left at this
point is:
$error
[1] "At least 80% of man pages documenting exported objects must have
runnable examples. The following pages do not:"
There are a few reasons why I'm using \dontrun{} for my examples and want
to know if there is any way to actually run my examples.
My package incorporates some automated data management and requires in
practice that certain directories exist.
I am storing some package environmental variables in my package like this:
myPackage_env <- new.env(parent=emptyenv())
assign("results_dir", "results/", envir=.myPackage_env)
My functions require things like this:
if(!exists("results_dir", envir=.myPackage_env))
{ stop(...) }
Maybe if I could somehow store the entire environment after a complete run
of my package and load that data then my functions might be able to run in
the @example sections.
How can I save the myPackage_env after an actual run of my package?
How can I make that data available to my @examples sections?
Thanks for any advice anyone can offer.
Best,
-Adam
[Bioc-devel] Including data for @examples to run
2 messages · Adam Price, Pariksheet Nanda
Hi Adam,
On Wed, Apr 25, 2018 at 2:35 PM, Adam Price <price0416 at gmail.com> wrote:
There are a few reasons why I'm using \dontrun{} for my examples and want
to know if there is any way to actually run my examples.
My package incorporates some automated data management and requires in
practice that certain directories exist.
You might consider decoupling the code logic that creates or requires such a directory structure, and you could have a wrapper function that takes the input + output paths as function parameters with some defaults. An R-ish way of setting package-wide defaults that might be a good fit for your use case is using options(), so you could have the flexibility of your input and output paths falling back to getOption(...) if they are not provided. Although that can be a little fragile if a user sets options() between related function calls. Another possibility might be to instantiate a class to keep a single instance of your path structure. I imagine there must be existing bioconductor packages that do this sort of thing, especially those that lightly wrap around other programs that create directories, like the Rbowtie2 package (Rbowtie2 checks for files and directory structures, but doesn't make use of classes). Maybe others on the list know of packages that come to mind or can comment on these ideas. Are you by any chance writing unit tests for your package? One of the really nice benefits of separating out the directory requirement is making your code more testable. I know that Bioconductor doesn't formally require tests for their packages, but even so they are very useful and often you can answer architectural decisions about how to best structure your code by how nicely it satisfies tests.
I am storing some package environmental variables in my package like this: myPackage_env <- new.env(parent=emptyenv())
I feel like in general using environmental variables for solving problems in computing is like reaching for the sledge hammer in your toolbox. Certainly, it has many legitimate uses, especially in cluster computing where you have to setup the environment for packages to find each other. Would it be possible to see a link to some your package code? Then we can comment more about the paths and environmental variables, and be more specific about alternatives and suggestions. These are very good questions. A lot of workflows don't lend themselves to being done entirely in memory, can rely on lots of existing files, and require better integration with software outside of the Bioconductor system, and it's fun to learn about how to tackle them.
-Adam
Pariksheet