[Bioc-devel] shiny, Bioconductor, and reproducible research

[Dan Tenenbaum]

Hi everyone,

There was a lot of talk about shiny at BioC2013 and it seems like a
lot of people are using it for lots of different cool stuff.

Now we are at the point where some contributors want to add shiny apps
to Bioconductor as packages.

We had some discussion internally and decided that there are a few
issues we wanted to discuss with BioC developers as well as some of
the shiny developers. Please feel free to share your thoughts.

1) Testing shiny apps

Typically, bioconductor packages have man page examples, vignettes,
and (sometimes) unit tests, so when we build the packages every day on
our build system, the code in all of these is evaluated and we have
some idea of whether the package is working as it's supposed to.

I'm not clear on how to do similar testing of a shiny application.
Since launching a shiny app takes away the R console (until the app is
closed), shiny apps should probably not be launched in example or test
code (unless interactive() is TRUE).

Do the shiny folks (or anyone else) have thoughts on testing shiny apps?

2) Reproducible research

Reproducible research is really important in our community, but shiny
apps are sort of a black box as far as reproducibility is concerned.

If shiny apps are "read-only" (that is, if they are just used to view
an object) then this is not really a problem. But shiny has the
ability now to change objects back in your R session, so we need to be
able to track what is done inside the shiny app.

shiny apps can return some sort of object that tells you what was done
in the shiny session (insofar as it modifies any objects in the
users's session) and this object can provide a way to reproduce those
steps without the shiny app. So maybe the object would consist of
lines of code. This means that if there is a shiny app, the package
author must also provide ways to do the same transformations on
objects without shiny.

There are probably other approaches as well. But the end goal would be
a scriptable, reproducible shiny session.

Another thought was that a shiny app could emit some sort of state
object, and then be restarted with that object.

Not sure if the place for such infrastructure is inside shiny itself,
or perhaps in a BioC infrastructure package.

What are your thoughts?
Dan