From arilamstein at gmail.com  Thu Mar 12 17:40:47 2015
From: arilamstein at gmail.com (arilamstein at gmail.com)
Date: Thu, 12 Mar 2015 09:40:47 -0700
Subject: [Rd] Best way to handle dependency on non-CRAN package / large
 data package?
In-Reply-To: <21761.48424.267182.677329@max.nulle.part>
References: <CAEO2kuJzie8_eFi0RYA=V5rUk4DYQa6OeuR21XypUdanJXVSyw@mail.gmail.com>
	<21761.48424.267182.677329@max.nulle.part>
Message-ID: <CAEO2kuLw=dvWQz2hWWRPnZiayV=xaZu-eH4beG4AhfmT_-axcQ@mail.gmail.com>

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]]



[Rd] Best way to handle dependency on non-CRAN package / large data package?
arilamstein at gmail.com