[R-pkg-devel] Has GitHub been used as a CRAN-style repository?

Henrik Bengtsson henrik.bengtsson at gmail.com
Wed Apr 27 22:05:40 CEST 2016

On Wed, Apr 27, 2016 at 12:40 PM, Ramon Diaz-Uriarte <rdiaz02 at gmail.com> wrote:
> Dear Bruce,
> On Wed, 27-04-2016, at 19:00, Bruce Hoff <bruce.hoff at sagebase.org> wrote:
>> Following up to my earlier post:  It looks like Dirk Eddelbuettel has in
>> fact built what I was asking for with 'drat',
>> https://github.com/eddelbuettel/drat.  The element that I do not see in
>> 'drat' is a way to build Mac and Windows binaries, so I have two follow up
>> questons:
>> (1) Has anyone extended 'drat' in this way, to create a continuous build
>> system, e.g. using Github to host the source of their R package and drat to
>> publish the binaries, with a source/Windows/MacOS build system in between?;
> Maybe appveyor (https://github.com/krlmlr/r-appveyor) could be of help here
> for the Windows part? Appveyor takes care of the continuous
> integration. But appveyor also allows you to define (at least some)
> "artifacts"; they are used regularly to download the package-name.Rcheck to
> examine the logs but maybe it could be tweaked to get it to produce the zip
> file.

Yes, AppVeyor CI can certainly output R CMD build artifacts, e.g.


This was using:



> (Note: this is just a quick idea and my experience with appveyor is fairly
> limited; I use to check that some of my packages in github work in windows,
> so maybe this will not do what you want).
> Best,
> R.
>> (2) Has CRAN 'open sourced' how they build on Windows and MacOS to allow
>> someone to duplicate their build process?  I'm familiar with Rtools,
>> https://cran.r-project.org/bin/windows/Rtools/installer.html, which is
>> certainly a key element, but is there a way to somehow clone the CRAN build
>> process, to have some assurance that one is building package binaries the
>> same way CRAN does?
>> Thanks,
>> Bruce Hoff
>> Sage Bionetworks
>> On Wed, Apr 27, 2016 at 6:37 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
>>> Bruce,
>>> As Ben and Thierry already mentioned (thanks!!) drat it pretty much
>>> designed
>>> to support that out of the box (but also supports repos elsewhere; however
>>> there are reasons such as gh-pages that make GitHub uniquely suited).  I
>>> have
>>> some moderately strongly-held beliefs about how install_github is IMHO
>>> unsuitable as a _release-mechanism_ which I think of as, say, tarballs
>>> taken
>>> at author-chosen points in time rather then semi-randomly selected commits
>>> you may end with.  And drat supports such releases.  We do have a few
>>> examples on CRAN for mixing CRAN with external releases, and some are in
>>> fact
>>> managed by drat.  We also rely on drat extensively at work for a local
>>> repo.
>>> When I first wrote drat about a year ago, not everybody "got it" -- so
>>> there
>>> are a bunch of vignettes, as well as my talk at useR! 2015 about.  Please
>>> peruse, and should you have questions do come back here (or file issues at
>>> it
>>> GitHub repo).
>>> Chaers, Dirk
>>> --
>>> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>>       [[alternative HTML version deleted]]
>> ______________________________________________
>> R-package-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> --
> Ramon Diaz-Uriarte
> Department of Biochemistry, Lab B-25
> Facultad de Medicina
> Universidad Autónoma de Madrid
> Arzobispo Morcillo, 4
> 28029 Madrid
> Spain
> Phone: +34-91-497-2412
> Email: rdiaz02 at gmail.com
>        ramon.diaz at iib.uam.es
> http://ligarto.org/rdiaz
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

More information about the R-package-devel mailing list