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