[R-pkg-devel] Depending on currently unreleased package

Jim Hester james.f.hester at gmail.com
Tue May 16 20:08:58 CEST 2017

You can use the `Remotes: ` feature in your DESCRIPTION file
implemented in devtools to automatically install development versions
of packages during development, including on Travis CI. However they
will need to be removed before submitting to CRAN, in which case a
conditional include like Duncan described is what you will need to do
until dbplyr is released on CRAN.

On Tue, May 9, 2017 at 7:54 PM, William Brannon <will.brannon at gmail.com> wrote:
> Thanks! That took care of it. I had been tripped up by how the R support in
> travis-ci throws errors if suggested packages aren't available.
> On May 6, 2017 4:18 PM, "Duncan Murdoch" <murdoch.duncan at gmail.com> wrote:
>> On 06/05/2017 4:02 PM, William Brannon wrote:
>>> Hi r-devel,
>>> I have a package called sqlscore (
>>> https://cran.r-project.org/package=sqlscore) which depends on dplyr
>>> functions for SQL generation. The new version of dplyr splits these
>>> functions into a different package (dbplyr) and provides a recommended way
>>> to wrap around access to the function in the appropriate package. So when
>>> it's released in a few days, users with the new dplyr will see errors when
>>> trying to use sqlscore. So far, so good, though - updating my R code as
>>> such isn't hard.
>>> But dbplyr won't be released before the new  dplyr is, and I can't figure
>>> out how to list it in Imports, Depends or even Suggests to release an
>>> update ahead of the new dplyr release. Doing so causes ERRORs in R CMD
>>> check about an unavailable dependency, and not doing so causes problems
>>> with "::" references to a package not mentioned in DESCRIPTION.
>>> I'd rather not wait until dbplyr is released to submit a new package, for
>>> obvious reasons. But releasing an update which depends on it before that
>>> might also cause breakage.
>>> Any suggestions for the right upgrade path?
>> You can list dbplyr in Suggests, and put in conditionals to test for it.
>> If you don't want to wait for its release you'll need to have code that
>> works without it as well, so something like this
>> if (requireNamespace("dbplyr"))
>>   foo <- dbplyr::foo
>> else if (packageVersion("dplyr") < "x.y.z")
>>   foo <- dplyr::foo
>> else
>>   stop("You need to install the dbplyr package, because dplyr::foo has
>> moved there.")
>> will allow you to use foo() anywhere (as long as its interface is the same
>> in both packages, of course).
>> Duncan Murdoch
>         [[alternative HTML version deleted]]
> ______________________________________________
> 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