Good question. Drat is an R package which makes it really easy to provide R packages via a repository, and also makes it easy to use such repositories for package installation and upgrades.
drat itself is a package, so it has source code (on GitHub) and a package (on the main R repository network).
But wait: we also call the repositories created or used via drat “drat” repositories. So we have to distinguish between “drat the package” and “a drat repository” created or used by it.
Hope this clarified things a little. Drat really can be different things which reside in different places but it aims to be a helper package which helps creating and using R package repositories easier.
Glad you asked. We have written
Several answers:
user uniquely identifies a URL user.github.io/drat/, and communicating a single variable is easier than communicating a full URLTaken together, we have this a pretty good to default on GitHub for repositories. But read on …
Fear not, as drat also supports repositories on a local drive, or shared network drive, or actually just about anything where you can write to or read from.
We detail that in the corresponding vignettes.
install_github() is a fine tool and does what it sets out to do: grab a snapshot from GitHub and install it. This can be the HEAD (by default), or a tag, or a commit, or from a branch.
But we think that is not what R needs. R has become so very successful for many reasons, but (in the eyes of many) one key part of the success was repositories ensuring both easy installation and easy upgrades.
That second point is lost on install_github(): it installs what we may call “orphans”. Packages that are disconnected from an upgrade path. (With the exception, of course, of a newer version of what you install appearing in a known repository so that update.packages will see it.) We think that is a disservice to the users, and a repository can do better in a fundamental way than provide access to (somewhat random) commits. Of course, one could write new code building on top of install_github() and adding the functionality. But then, why? R already has this functionality, and had it for decades: using repositories. So drat does not aim to replace install_github(); it simply aims at something both different and possibly much simpler.
Moreover, drat puts the “release” option back into the hand of the package authors. By cutting a release tarball and placing it into a repository, we think a possibly more informed release snapshot is distributed than by pointing at any branch of repository.
And last but not least, drat (>= 0.0.4) and its repositories also support binary installations.
You bet. Jan Schulz provided a careful pull request to provide initial support upon which we have built. As of release 0.1.0, this should just work.
Additional_repositories ?Glad you asked! See the last line of the DESCRIPTION file of the wikipediatrend package and its official repository page. It very happily uses the ghrr drat repo to provide the two suggested packages AnomalyDetection and BreakoutDetection.
The miniCRAN package creates self-sufficient repositories by examining the dependency graph and downloading all dependent packages. As such, it is more of complement to drat than an alternative — and Word is that several people have in fact combined both.