eddelbuettel / drat Goto Github PK

I am new to using the drat package, but in general I seem to have it working. I have built a local repository stored on a Windows network drive at our office. I can successfully add the repo using:
drat::addRepo("LocalRepo", "file:S:/shared/files/LocalRepo")
at this point install.packages("LocalPackage", type= "source") works perfectly. However, if I try to add a package from the CRAN repositories:
> install.packages("ggplot2")
I get the following:
Warning in install.packages : cannot open compressed file 'S:/shared/files/LocalRepo/bin/windows/contrib/3.4/PACKAGES', probable reason 'No such file or directory' Error in install.packages : cannot open the connection

Is there a way to avoid this problem?

I am curious to know why addRepo does not also set the dratRepo option or at least have it do it optionally. I don't think most of the users have multiple drat repositories and I suspect they are using the same drat repository as both module user and authors. At present me .Rprofile sets both. Seems a bit odd from the interface perspective.

Currently, insertPackages() silently overwrites an existing tar.gz of the same version. This default seems dangerous. Would you support an overwrite argument to insertPackages(), defaulting to FALSE?

My impression is that when a new version of a package is added, the older versions are removed. Shouldn't they be added to a CRAN-style /Archive/PkgName directory instead (at least optionally)?

Thank for this super handy package.

Is there any appetite for a function that removes completely a package from a drat repo? It is very possible that I am misunderstanding how drat works and if that is the case I apologize. Right now from this issue #18 , I learned of pruneRepo(). So this is great in that I can generate a vector of the package I'd like to remove like so:

pruneRepo(repopath = "C:/_dev/GitHub_repos/drat", pkg = "PACKAGE_NAME")

Then as recommend I can use git rm to remove the PACKAGE_NAME.tar.gz file. But all other elements of the package are left in PACKAGES, PACKAGES.gz, and PACKAGES.rds. Is there any way to remove those? The remove=TRUE args of pruneRepo seems set up to remove the *.tar.gz file but not the other elements.

Again great package, really fills a need. Any insight on this would be much appreciated.

Any canonical way of defining .travis.yml file to use packages from drat?
As workaround we can use r_github_packages and point particular commit in package repo.
Maybe some trick to addRepo before running r_packages step? similar way as we can add PPA in before_install and then install added package listing it in apt_packages.
If there is no easy to use drat with travis I would like to fill FR for this.

So user can have better control over what metadata are being part on the PACKAGES index file.

A FR for new function insert package dependencies to mirror all non-locally stored packages.
It could take package and repos arguments and download all the R dependencies recursively - latest tar.gz sources.
The advantage is to create sustained environment for your package, well historized, easy to maintain, and would work for offline installation.

Looks like an interesting package. I cannot install it from Git Hub, though:

> devtools::install_github("eddelbuettel/drat")
Downloading github repo eddelbuettel/drat@master
Error: Found continuation line starting ' Two primary types o ...' at begin of record.

Seems to be a bug in getPackageInfo
In regex in linked line seems that getPackageInfo is not handling dots in package name.

gsub("^([a-zA-Z0-9]*)_.*", "\\1", "my.pkg_1.0.0.zip") # should return "my.pkg"
# [1] "my.pkg_1.0.0.zip"

Which later results in error.
To reproduce take the zip binaries of package with dots in the name and try insertPackage() on it.

R version 3.2.2 (2015-08-14)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.3 LTS

locale:
 [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C               LC_TIME=en_GB.UTF-8        LC_COLLATE=en_GB.UTF-8     LC_MONETARY=en_GB.UTF-8   
 [6] LC_MESSAGES=en_GB.UTF-8    LC_PAPER=en_GB.UTF-8       LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] drat_0.1.0

loaded via a namespace (and not attached):
[1] tools_3.2.2  git2r_0.10.1

More or less just for the reference: using the readme example to install directly from github does not work:

> install.packages("drat", repos="http://eddelbuettel.github.io/drat")
Installing package into ‘C:/portabel/Rlibs’
(as ‘lib’ is unspecified)
Warning in install.packages :
  cannot open: HTTP status was '404 Not Found'
Warning in install.packages :
  cannot open: HTTP status was '404 Not Found'
Warning in install.packages :
  unable to access index for repository http://eddelbuettel.github.io/drat/bin/windows/contrib/3.1

   package ‘drat’ is available as a source package but not as a binary

Warning in install.packages :
  package ‘drat’ is not available (as a binary package for R version 3.1.3)

On Windows, a path with a trailing slash is NOT a file.

file.exists("//local/PRAN/") # false
file.exists("//local/PRAN") # true

Currently (drat 0.1.0), the following line errs because of the trailing slash. Here "//local/PRAN/" is a local network folder.

insertPackage("pkg_1.tar.gz", "//local/PRAN/")

Error: Directory //local/PRAN/ not found

Without the trailing slash, the function call works fine

insertPackage("pkg_1.tar.gz", "//local/PRAN")

This feature request is just a "nicety" for people like me that accidentally add the trailing slash and wonder why insertPackage cannot find the directory.

It is unclear if drat supports a repo that provides download access to old packages. Say I deploy ggplot 3.0.0, then decide to deploy 3.2.1 using the archive option to insertPackage(). Is the repo still able to provide 3.0.0 if requested e.g with devtools::install_version()?

It seems to me that to provide this functionality, a Meta directory must also be present, not only Archive. Is there functionality to create this directory and its content?

I have tried to set up a repository to make life easier for others, but they seem to run in trouble (I have had no problems, but everything works smoothly for me). On the first day, I have had two messages of failures, both from Windows 10 users, and both with this error message:

(converted from warning) unable to access index for repository jarioksa.github.io/drat/src/contrib:
scheme not supported in URL 'jarioksa.github.io/drat/src/contrib/PACKAGES'

Is there anything I can do (apart from closing the repository)?

Background & Details:

The package in the repository is not downloaded directly, but it is a non-CRAN package that is needed by another package in github (let's call it the Main Package). In that package I had in DESCRIPTION:

Additional_repositories: jarioksa.github.io/drat

The Main Package is in github (and will remain there unless we can fix this issue), and the users have applied devtools::install_github() to install the Main Package, and the idea was that this non-CRAN package would be looked at the drat directory if needed. In my system this worked OK both in the R CMD check --as-cran and also worked when I tried installation. However, it failed with users. A funny thing here is that neither of these users actually needed this drat package because they had followed our more involved instructions and already installed the package. The installation still wanted to peek at the Additional_repository, but it could not do so – at least not in Windows 10 (n = 2).

After the first report, I used Win-Builder to produce a Windows binary of the package and also inserted that into the repository, but the second report came several hours later so that this probably did not help.

Is there something we can do, or is it best to forget drat?

Thanks for this terrifically useful package.

The branch that drat commits, gh-pages, is hardcoded. This is sensible in general, but for user or organization Github pages (i.e. user.github.io) Github requires those files to be stored in the master branch of a repo named user.github.io. Because of the hardcoding, it isn't possible to use drat to create a drat repo in such a Github repo.

What do you think of adding a field in insertPackage() for branch name, i.e. insertPackage(branch = "master")? Happy to add a PR.

Following casual testing, this looks like a nice addition.

Probably as a Suggests: only, with a if (requireNamespace(...)) around it to not force it onto everybody.

According to the man page for addRepo, "Exactly one of ‘account’ or ‘alturl’ must be provided" but

> drat::addRepo(alturl = "http://rattle.togaware.com")
Error: Please provide either 'account' (and if desired 'alturl').

If the functionality described on the man page was intended, it seems the update below would fix this error.

addRepo <- function(account, alturl) {
    r <- getOption("repos")
    if (!missing(account) && missing(alturl)) {
        for (acct in account) {
            r[acct] <- paste0("http://", acct, ".github.io/drat/")
        }
    } else if (!missing(account) && !missing(alturl)) {
        r[account] <- alturl
    } else if (missing(account) && !missing(alturl)) {
        r[alturl] <- alturl
    } else {
        stop("Please provide either 'account' (and if desired 'alturl').", call.=FALSE)
    }
    options(repos = r)
    invisible(r)
}

Looks like vignettes needs to be rendered by rmarkdown package which is not specified as suggested dependency, so may not be present.

$ R CMD build .
* checking for file ‘./DESCRIPTION’ ... OK
* preparing ‘drat’:
* checking DESCRIPTION meta-information ... OK
* installing the package to build vignettes
* creating vignettes ... ERROR
Warning in engine$weave(file, quiet = quiet, encoding = enc) :
  The vignette engine knitr::rmarkdown is not available, because the rmarkdown package is not installed. Please install it.
Error: processing vignette 'CombiningDratAndTravis.Rmd' failed with diagnostics:
It seems you should call rmarkdown::render() instead of knitr::knit2html() because CombiningDratAndTravis.Rmd appears to be an R Markdown v2 document.
Execution halted

This is common case...
Rdatatable/data.table@b6c6470
tidyverse/dplyr@97d6b50

Similar to setting the working directory back to the curwd in https://github.com/eddelbuettel/drat/blob/master/R/insertPackage.R#L82 , could the same be done after maybe commit'ing https://github.com/eddelbuettel/drat/blob/master/R/insertPackage.R#L125 .

It would really be helpful when supplying relative routes for the repodir and trying to prune or archive after commit'ing.

Thank you for the awesome package!

• Barret

The function insertPackage seems to have the side effect to change the working directory. Actually it is set at several places, but in the case of commit = TRUE it is not reset to curwd. Maybe a

on.exit(
  setwd(curwd)
)

takes care of it and avoids repetition for all if-clauses. Furthermore it would restore the working directory even if errors occur...

A package that I am developing is larger than the 100mb limit of GitHub repositories (it contains OpenCV sources). I therefore opted to use git-lfs with my drat repository in order to allow this package to be pushed to my drat repository. Unfortunately it seems that drat does not download the tar.gz of the package when called from R but rather the text pointer created by git-lfs and pointing toward the actual location of the tar.gz.

I am trying to evaluate whether drat is useful for distributing packages internally on a shared windows network, and I am running into trouble when trying to install inserted packages.

I did the following:

1. Built a source package
2. drat::insertPackage("pkg_1.0.0.tar.gz", "S:/path/to/drat")
3. In another session, drat::addRepo("localRepo", "S:/path/to/drat") and install.packages("pkg", type = "source")

I get the warnings:

Warning in install.packages :
  unable to access index for repository S:/path/to/drat/src/contrib
Warning in install.packages :
  unable to access index for repository S:/path/to/drat/src/contrib
Warning in install.packages :
  package ‘pkg’ is not available (for R version 3.2.0)

The folder structure created contains:

S:/path/to/drat
  /src
    /contrib
      PACKAGES
      PACKAGES.gz
      pkg_1.0.0.tar.gz

What am I missing? Or is there a bug (most likely me)?

Currently this fails for me:

install.packages("AnomalyDetection", repos = "http://ghrr.github.io/drat")
# curl: (22) The requested URL returned error: 404 Not Found
# Warning in install.packages :
#   download had nonzero exit status
# Warning in install.packages :
#   cannot open compressed file '/tmp/RtmpEjkcSn/file1132c43359019', probable reason 'No such file or # directory'
# curl: (22) The requested URL returned error: 404 Not Found
# Warning in install.packages :
#   download had nonzero exit status
# Warning in install.packages :
#   cannot open compressed file '/tmp/RtmpEjkcSn/file1132c43359019', probable reason 'No such file or # directory'
# Error in install.packages : cannot open the connection

I think the warnings are caused by the libcurl buglet @kevinushey reported - 404s don't get converted into R errors.

Things are a bit better if I use the older internal method:

> install.packages("AnomalyDetection", repos = "http://ghrr.github.io/drat", method = "internal")
Installing package into ‘/Users/hadley/R’
(as ‘lib’ is unspecified)
Warning in install.packages :
  cannot open: HTTP status was '404 Not Found'
Warning in install.packages :
  cannot open: HTTP status was '404 Not Found'
Warning in install.packages :
  unable to access index for repository http://ghrr.github.io/drat/bin/macosx/mavericks/contrib/3.2
installing the source package ‘AnomalyDetection’
... and the package installs

Although there's still two warnings about 404s.

I wonder if it would be worthwhile for drat to also generate a dummy binary directory structure so that this would work more cleanly.

I configured a Github access token with the wrong permissions, leading to a failure to fetch my drat repo. The failure resulted in an error that published the access token (see very bottom of build here). Is it possible to modify the deploy.sh (from the Travis vignette) so that it can't do that?

I don't know if this is in the spirit of the drat, but a utility function for downloading a package (of a specific version) and inserting it into the drat repository would be very convenient.

on newer OSX (currently mavericks and yosemite) versions, the pkgType is mac.binary.mavericks, and the path file.path("bin", "macosx", "mavericks", "contrib", rversion)

you don’t handle that

I'll put all my edit on help documents here. They are relatively minor, no need to create separate issue for each topic.

1. addRepo
   See changes here. Only the R file diff is needed since Rd is generated.

   I removed one extra (, added notes of getOption("repos"), modified the first code example which can be confusing, because user will not expect "drat" to be a github user name.

I've created a simple drat repository here, with a call to drat::initRepo() and then drat::insertPackage("sashimi_0.0.1.tar.gz") for a locally built package sashimi. All is well with:

install.packages("sashimi", type = "source")

However (as is default on non-Linux systems), using type = "both"

install.packages("sashimi", type = "both")

gives a warning:

curl: (22) The requested URL returned error: 404 Not Found
Warning in read.dcf(file = tmpf) :
  cannot open compressed file '/var/folders/tm/5dt8p5s50x58br1k6wpqnwx00000gn/T//RtmpyPMPgH/file9d6b4875028d', probable reason 'No such file or directory'
Warning: unable to access index for repository http://kevinushey.github.io/drat/bin/macosx/mavericks/contrib/3.2:
  cannot open the connection

Not surprising since http://kevinushey.github.io/drat/bin/macosx/mavericks/contrib/3.2 does not exist.

It would be useful if drat populated the common binary 'arms' of the repository with an empty PACKAGES file by default, to avoid this warning.

Packrat has some repository management tools that help do this:

https://github.com/rstudio/packrat/blob/master/R/cranlike-repositories.R#L31-L44
https://github.com/rstudio/packrat/blob/master/R/cranlike-repositories.R#L58-L71

Would you be willing to accept a PR that created skeletons for these paths?

I have created a repository on github enterprise, but am unable to install anything from it yet. I imagine (hope) it may be possible to install packages from the enterprise repository, by passing the correct value to the extra argument in download.file() (via the ... argument of install.packages()), however, I haven't had any success so far.

Are the following functions not exported intentionally?

• getPathForPackageType()
• identifyPackageType()

If so, the documentation is misleading.

This is not really an issue (in the sense that it's a drat bug that needs fixing), but more a report on a problem I ran into (as well as others before me #81, #71, #46) and there even exists a (not-accepted) PR for fixing this (among other things): #73.

Following the hurricaneexposuredata idea, I set up a gh-pages based drat repository with the following folder structure:

|- src
   |- contrib
      |- datapackage_1.0.0.tar.gz
      |- PACKAGES
      |- PACKAGES.gz
      |- PACKAGES.rds

and I use this repository in another package by having the following in it's DESCRIPTION

Suggests:
  datapackage
Additional_repositories: https://user.github.io/repo-name

As datapackage does not require compilation (and being a data package, size is not negligible), it does not make sense to add binary sources to the repo.

Unfortunately, under Win/Mac OS such a setup can cause issues, as remotes::install_deps() will fail because utils::install.packages() throws a warning. This can be remedied by doing any of

• set R_REMOTES_NO_ERRORS_FROM_WARNINGS to true (a bit broad, as will apply to all deps)
• you pass type = "source"/specify contriburl which remotes::install_deps() will forward to utils::install.packages() (not ideal in CI environments)
• add some empty PACKAGES files in the appropriate places below bin/ (the solution in #73)

Personally, I feel that this should either be mentioned in the docs or that parts of #73 should be reconsidered as it did take some time for me to the to the bottom of this. I'm happy to look into salvaging this aspect of #73. What do you think @eddelbuettel?

TL;DR: I would like to change install_version() so that it will search for the requested version of the package in each of the repositories given, in sequence.

Motivation: my company uses R internally, creating packages for various projects and publishing them to internal CRAN-alike servers for integration by other teams. We have one “cran-stable” for official releases, and one CRAN-alike that updates with new snapshots every time someone pushes to a “develop” branch.

I would like our team to call install_version(pkg, version, repos), which then iterates over each entry of repos until a suitable version is found.

For instance, we might have the following:

• http://myserver/cran-stable:
• MyPackage_0.23.tar.gz
• http://myserver/cran-dev:
• MyPackage_0.24-283.tar.gz

repos <- c(Stable="http://myserver/cran-stable",
              Dev="http://myserver/cran-dev",
             CRAN="https://cran.revolutionanalytics.com")
install_version('MyPackage', '0.23', repos)  # Installs from ‘Stable’
install_version('MyPackage', '0.24', repos)  # Installs from ‘Dev’

Right now, it looks like install_version() expects exactly one version of a package to be officially published across all repositories, and it only knows how to look for alternate versions in archive/ directories, under the assumption that the only alternate versions that could exist are previously-published versions.

Also, because packages in the “Dev” server may have versioned dependencies on packages from either repository, the same semantics would need to apply to the dependencies too, so install_version() would call itself recursively to handle them.

I would be happy to work this up as a pull request that keeps the existing semantics of finding packages in archive/ directories too.

Currently it returns NULL. It would be nice to have relative path returned of the package that was inserted. For source package it is easy (src/contrib/...tar.gz) , but for binaries packages one would need need to use getPathForPackage (internal function). So returning relative path to repodir would helps in further actions that depends on inserted package.

It looks like there was a bit of a discussion in this issue, #52 (comment), about using S3. But I figured it was worth asking in a separate issue.

Is there any current or planned support for inserting packages to S3? The idea being that you turn on static hosting for a bucket and simply point users to that bucket URL for the repo.

This is wrong:

R> drat:::identifyPackageType("foo_1.2.3_R_x86_64-redhat-linux-gnu.tar.gz")    
[1] "source"
R>

We can probably use platform in a first attempt:

R> pf <- R.version[["platform"]]
R> pf
[1] "x86_64-redhat-linux-gnu"
R> grepl(pf, fn)
[1] TRUE
R> 

Would you be interested in a build function? I'm thinking something like:

build <- function(pkg_dir=".", check=FALSE){
  if(check) # R CMD check pkg_dir
  # Next
   #Call R CMD build pkg_dir
   return(pkg_dir)
}

Then in the insert function, if the file argument points to a directory, call build.

A common use-case I think would be to add an active project to one's local drat repo, e.g. from the directory of an in-development R package I might run:

insertPackage(devtools::build(), commit=TRUE)

a quick push and now folks can install releases of my in-development package without CRAN or install_github.

The following code:

drat::insertPackage('/home/spav/trunk/code/r/staging/foo.plot_0.1.tar.gz',
 repodir='/mnt/NAS/installers/r/drat/')

fails with an error like:

In file.copy(file.path(curwd, file), srcdir, overwrite = TRUE) :
  problem copying /home/spav/myworking/directory/basically/pwd//home/spav/trunk/code/r/staging/foo.plot_0.1.tar.gz  to /mnt/NAS/installers/r/drat//src/contrib/foo.plot_0.1.tar.gz: No such file or directory

I am using drat 0.2.0 with git2r, from the directory /home/spav/myworking/directory/basically/pwd

Hi Dirk,

I'm finally came around giving drat a test drive and so far I like it a lot!

Only problem though: everything works fine locally, but my github.io URL (http://rappster.github.io/drat) does not seem to work as I'm getting a 404 error.

Here's what I did:

1. I followed the instructions in your vignette which resulted my drat repo: https://github.com/rappster/drat
2. I build my package and added it to the repo via drat::insertPackage(...)
3. I pushed my local git repo state (branch gh-pages) to GitHub and also made gh-pages the default branch (probably not necessary, but that's the last thing I could come up with for troubleshooting)

Any clue of what might have gone wrong?

insertPackage.R supported customized branch name through getOption("dratBranch", "gh-pages"). However initRepo doesn't support this yet.

For insertPackage, I made a minimal change to add branch as a parameter here.

There is default value, and it's still taken from option, so previous usage will not be interfered. But a parameter make it easier for user to make one time change - most users will use gh-pages as default option, but maybe change one time for certain repo. The option approach will make this usage awkward.

macOS R now looks in "bin/macosx/el-capitan/contrib", not "mavericks".

R> contrib.url(getOption('repos'), type=.Platform$pkgType)
[1] "https://cloud.r-project.org/bin/macosx/el-capitan/contrib/3.4"  

It seems this stems from the fact that on R 3.4, .Platform$pkgType returns "mac.binary.el-capitan", but getPathForPackage doesn't know about this. This is documented deep in the R documentation about package installation.

If I understand the blog post correctly, from next Wednesday any new github.io pages created will enforce a https connection. This means that addRepo on the CRAN version of drat won't work.

Fortuitously the developmental will be fine.

This will be one of several issues created by me. I think it's easier to discuss each individually. It includes several points, but all about documentation.

using customized github repo name

drat name is a little bit odd to me, though it's not a real problem as a package name. However users may want to create their github repo with a different name. drat will be alien for anybody heard it in first time.

The documentation all assumed the github repo will be named as drat. It seemed that you can customize the repo name through drat::initRepo, but I didn't find how to work with customized name with other functions according to help and vignettes.

If I have more time I could try it and find out more details. For now I suggest at least make it obvious in documentation.

drat package users don't even need to install drat

I understand the drat::addRepo usage has the advantage that user can upgrade packages later. But that only works if user keep it in options permanently. Since almost every drat package will has its own drat repo, that could means quite some repos saved in user options. And every normal package installation will need to check every repo in list.

I think it's often favorable to just use the repo in session for one time. Then why not just tell package user that they don't even need to install drat? Of course drat is very small and with little dependencies, still one less dependency may be a positive point for end users.

I suggest to add some example like this in the vignette for package users:

install.packages("pkgname", repos = c(getOption("repos"),
                                      "full drat repo url"))

I finally tried to host my package in drat, it's simpler than what I thought, but with some minor details.

One minor issue is that install.packages tries to find binary package first and gives error messages when only source packages are hosted.

> drat::addRepo("ctmm-initiative")
> install.packages("ctmmweb")
Warning in install.packages :
  unable to access index for repository https://ctmm-initiative.github.io/drat/bin/macosx/el-capitan/contrib/3.4:
  cannot open URL 'https://ctmm-initiative.github.io/drat/bin/macosx/el-capitan/contrib/3.4/PACKAGES'
installing the source package ‘ctmmweb’

It doesn't block any work, just some warnings may surprise users and make them to thinking something is wrong.

However if I keep the drat repo in options, installing any other package will have this warning too

> install.packages("git2r")
Warning in install.packages :
  unable to access index for repository https://ctmm-initiative.github.io/drat/bin/macosx/el-capitan/contrib/3.4:
  cannot open URL 'https://ctmm-initiative.github.io/drat/bin/macosx/el-capitan/contrib/3.4/PACKAGES'
trying URL 'https://cran.rstudio.com/bin/macosx/el-capitan/contrib/3.4/git2r_0.21.0.tgz'

This becomes annoying now.

Can we create an empty binary package index to avoid this warning?

Suppose I have a packages I want to share with a few remote friends.

I was thinking I could either use a private GitHub repo, or host the packages on a virtual server (such as amazon EC2) and let me friends use that server as the repository. I couldn't see anything in the documentation that implies this is possible though.

Is there/could there be a way to support this?

Just an obvious feature request: if it is easy, it would be great if pruneRepo could prune all files, and not just the sources...

Thanks for this very useful package!

Best,
Alex

I'm trying to use devtools::install_version in conjunction with packages that have been saved to an internal repo using insertPackage with action = "archive". This process fails due to remotes::package_find_repo being unable to find the archive index file at /src/contrib/Meta/archive.rds. It appears that insertPackage does not create/update an index file at this location.

Could functionality for writing an archive package index be included in archivePackages or is this best done outside of this package?

Hi @eddelbuettel ,

Is there a way to remove a repo with a higher version number (e.g. with pruneRepo?) I've encountered the case where a developer accidentally committed a higher version number on an older set of sources cloudyr/aws.s3#22 (comment) and wonder if I just need to remove the package src and edit PACKAGES etc manually now...

Hi, I was wondering if there is a way to remove a package. For instance, I cloned drat and I have several drat packages in my gh-pages branch. But I do not think I should host it if I don't intend to keep it up to date. Also one may want to remove ancient copies of a package, or versions that have been found in breach of some arcane policy. I thought that a git rm followed by a commit and push would do it, but one needs to open a shell and the PACKAGES file would become inaccurate. Am I missing something or could this be a reasonable new feature proposal? Thanks

I use minicran to create a repo on github (https://github.com/mostly-harmless/radiant_miniCRAN). This provides some control over dependencies when a few hundred students are using your software. Drat seems like an interesting option to enhance the workflow. Does drat also work with binary files?