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 <e...@debian.org> wrote: > > On 12 March 2015 at 08:41, arilamst...@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 | e...@debian.org > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
