The hardware and bandwidth for this mirror is donated by METANET, the Webhosting and Full Service-Cloud Provider.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]metanet.ch.
2015-03-27
Note: This was originally a guest post by Steven on Dirk’s blog.
After playing around with drat for a few days now, my impressions of it are best captured by Dirk’s quote:
It just works.
To get some idea of what I mean by this, suppose you are a happy
consumer of R packages, but want access to, say, the latest, greatest
releases of my distribution package, sadist. You can simply
add the following to your .Rprofile file:
drat:::add("shabbychef")After this, you instantly have access to new releases in the github/shabbychef drat store via the package tools you already know and tolerate. You can use
install.packages('sadists')to install the sadists package from the drat store, for example. Similarly, if you issue
update.packages(ask=FALSE)all the drat stores you have added will be checked for package updates, along with their dependencies which may well come from other repositories including CRAN.
The most obvious use cases are:
Micro releases. For package authors, this provides a means to get feedback from the early adopters, but also allows one to push small changes and bug fixes without burning through your CRAN karma (if you have any left). My personal drat store tends to be a few minor releases ahead of my CRAN releases.
Local repositories. In my professional life, I write and maintain
proprietary packages. Pushing package updates used to involve saving the
package .tar.gz to a NAS, then calling something like
R CMD INSTALL package_name_0.3.1.9001.tar.gz. This is not
something I wanted to ask of my colleagues. With drat, they can instead
add the following stanza to .Rprofile:
drat:::addRepo('localRepo','file:///mnt/NAS/r/local/drat'),
and then rely on update.packages to do the rest.
I suspect that in the future, drat might be (ab)used in the following ways:
Rolling your own vanilla CRAN mirror, though I suspect there are better existing ways to accomplish this.
Patching CRAN. Suppose you found a bug in a package on CRAN (inconceivable!). As it stands now, you email the maintainer, and wait for a fix. Maybe the patch is trivial, but suppose it is never delivered. Now, you can simply make the patch yourself, pick a higher revision number, and stash it in your drat store. The only downside is that eventually the package maintainer might bump their revision number without pushing a fix, and you are stuck in an arms race of version numbers.
Forgoing CRAN altogether. While some package maintainers might find this attractive, I think I would prefer a single huge repository, warts and all, to a landscape of a million microrepos. Perhaps some enterprising group will set up a CRAN-like drat store on github, and accept packages by pull request (whether github CDN can or will support the traffic that CRAN does is another matter), but this seems a bit too futuristic for me now.
In exchange for writing this blog post, I get to lobby Dirk for some features in drat:
I shudder at the thought of hundreds of tiny drat stores. Perhaps
there should be a way to aggregate addRepo commands in some
way. This would allow curators to publish their suggested lists of
repos.
Drat stores are served in the gh-pages branch of a
github repo. I wish there were some way to keep the index.html file in
that directory reflect the packages present in the sources. Maybe this
could be achieved with some canonical RMarkdown code that most people
use.
These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.