Question

I am writing an R package called slidify which makes it easy to generate reproducible HTML5 slides from R Markdown files. The package makes use of css and js files from several existing HTML5 slide generation frameworks like dzslides, deck.js etc. Currently, I have organized the downloaded versions of these external assets in the inst/libraries folder of slidify, so that it is automatically available for users upon installation. While this approach is simple, there are some disadvantages:

1. These frameworks are constantly updated on github. Under the current setup, I would have to push a new version of the package everytime any of these frameworks are updated.

2. If I make any tweaks to the default css and js that come with these frameworks, then I need to merge the updates carefully so that I don’t lose slidify specific customizations.

I had a couple of thoughts on how to manage this.

1. Don’t package these libraries with slidify. Instead, provide a function that would allow users to add the frameworks they desire.

2. Add these frameworks to the inst\libraries folder on slidify, but as submodules. Now, I have no idea if adding them as submodules would get them installed if someone were to use devtools::install_github.

So my question is, when writing an R package how can I manage external non-R dependencies which are updated constantly?

Answer 1

One analogous situation is to look at the packages xlsx and XLConnect.

Both packages depend on Java libraries. xlsx defines (and depends on) a stand-alone package xlsxjars that only contains the libraries.

In this way, the downstream code is decoupled from the libraries.