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:
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.
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.
Don't package these libraries with slidify. Instead, provide a function that would allow users to add the frameworks they desire.
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?
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.
I solved a similar issue by using git-subtree. Have a look at: Managing 3rd party sources and binaries used by code under source control
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With