rsconnect::writeManifest Fails in Projects Using packrat

I have noticed that, at least on macOS 10.14.5, rsconnect::writeManifest fails with the following error in projects that use packrat:

Error in data.frame(Source = source, Repository = repository) : 
  arguments imply differing number of rows: 1, 0

I have created two GitHub repositories to demonstrate this using the default Shiny app that is created when creating a Shiny project in RStudio:

With some effort, I managed to locate the source of the error in rsconnect:::snapshotDependencies. The error is being thrown by the following line:

data.frame(Source = source, Repository = repository)

However, the actual source of the error is within the creation of the repo.lookup data frame:

repo.lookup <- data.frame(
    name = names(named.repos),
    url = as.character(named.repos),
    contrib.url = contrib.url(named.repos),
    stringsAsFactors = FALSE)

More specifically, the issue is caused by the contrib.url(named.repos) call.

Since the type parameter is not explicitly specified, it defaults to getOption("pkgType"). In projects that use packrat on macOS 10.14.5, the value of getOption("pkgType") is "mac.binary.el-capitan"; however, in normal projects (i.e. ones that do not use packrat), the value of getOption("pkgType") is "both". As stated in the documentation for contrib.url:

If type = "both" this will use the source repository.

Given that previous calls to contrib.url explicitly pass type = "source" in the parameters, if the value of the pkgType option is not "both" or "source", then the contrib.urls found in the repo.lookup data frame will not match those in the repo.packages data frame, and so the repository value will be missing in the data.frame call that ends up throwing the error.

Currently, the only way to resolve this issue without modifying the source of rsconnect:::snapshotDependencies is to ensure that the pkgType option is properly set prior to calling rsconnect::writeManifest.

However, it seems to me that if type = "source" is explicitly passed into other calls to contrib.url, it should be passed into the call in the repo.lookup data frame creation as well.

1 Like

Thanks for the bug report! Your diagnosis is exactly correct -- I can reproduce this as well and have a candidate fix for this issue at


Thanks for taking the time to create a pull request for the fix!