[Bioc-devel] Including data for @examples to run

[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

	[[alternative HTML version deleted]]