[Rd] Best way to handle dependency on non-CRAN package / large data package?

arilamstein at gmail.com arilamstein at gmail.com
Thu Mar 12 17:40:47 CET 2015

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

	[[alternative HTML version deleted]]

More information about the R-devel mailing list