Best way to handle dependency on non-CRAN package / large data package?
Thanks Dirk. I'm looking at it now. At first glance your documentation brings up a good limitation of simply telling users to type "devtools::install_github()". Namely, what happens when the census bureau updates their shapefiles, and I subsequently decide to update the package? Or if I discover an error in the package and decide to update it? The choroplethr package could have a dependency, and it's not clear how to make that dependency explicit to the user.
On Thu, Mar 12, 2015 at 9:22 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
On 12 March 2015 at 08:41, arilamstein at gmail.com wrote:
| But I don't know if this is the best way to do this, or if there is
| anything else to consider. I have never had to manage package
dependencies
| outside of CRAN, and have always thought of CRAN as being a "closed
| ecosystem", where there were not any dependencies outside of CRAN.
|
| Can anyone provide guidance on this?
drat can help with this problem. Have a look at
http://dirk.eddelbuettel.com/code/drat.html
as well as my blog and the GitHub repo of drat.
In a nutshell, it creates repositories you can access via update.packages()
and install.packages() as if they were CRAN or BioC. It also uses GitHub
to
automagically provide a repository server via the webserverd "embedded" in
each GitHub repo (and turned on as soon as you use the gh-pages branch).
Some package authors have turned to using drat to distribute packages
(often
in addition to CRAN, you can also do it instead of CRAN given a constraint
as
here). One such package author and I are working on another short blog
post
detailing just this. If you want, I can send you an 'informal preview' as
yet another source of documentation.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org