6

I'm developing an R package that works as a wrapper for functions from the parallel and Rhpc packages called ctools. I know that if I want my package to require these packages I need to include them in the Imports section of the DESCRIPTION file. When installing my package, these packages will be installed from CRAN. Similarly I can put them in the Suggests section if they aren't required, but useful. These won't be installed with my package.

But, I've forked the Rhpc package and added a function that I use in my ctools package. How do I get my package to Suggest/Import this package from my GitHub repo so of instead of installing the Rhpc package, it executes devtools::install_github("bamonroe/Rhpc")?

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
Brian Albert Monroe
  • 720
  • 8
  • 19

1 Answers1

11

From the manual (and quoting source here):

@c DESCRIPTION field Additional_repositories

The @samp{Additional_repositories} field is a comma-separated list of repository URLs where the packages named in the other fields may be found. It is currently used by @command{R CMD check} to check that the packages can be found, at least as source packages (which can be installed on any platform).

You can add the package to Suggests: and point to additional repositories -- possibly created using drat. There used to a package doing that, and IIRC there is another one doing it now but its name escaped me now.

Edit: Found it! See here in the source DESCRIPTION file of RNeXML -- and note how the line disappears in the posted DESCRIPTION on CRAN. Better still, note how two of the packages in Suggests: are not listed a hyperlinks on CRAN. I thinks those come from the additional repos. And yes, rOpenSci uses drat to manage that.

Edit 2: And just to close the loop, you (easily) use drat to host such an additional repo on GitHub -- the prime use case for drat.

Edit 3: RNeXML has dropped the additional repository, but the github history still has it.

Edit 4: Currently (i.e. on 2020-03-13), the CRAN packages EMC, bcmaps, blkbox, broom.mixed, epikit, grattan, gtsummary, hurricaneexposure, memoise, multinomialeq, noaastormevents, pointblank, provSummarize, provViz, spData, swephR, tashu, taxadb, waveformbildar all list a field Additional_repositories containing a URL pointing to a drat repo.

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
  • Great stuff! I'm reading through your drat basics page now. So I create a repository on GitHub, potentially by forking your drat git repo, point to my newly created repository in the `Additional_repositories` field of my `DESCRIPTION` file, and then add my forked version of Rhpc to the suggests line like it was any other package? Not that it's a problem, but would I have to change the name of my forked Rhpc? It seems like there would be a namespace confusion between the CRAN version and mine. – Brian Albert Monroe Mar 19 '16 at 18:34
  • Yes, in that case you probably want a different name for Rhpc or at least a higher number. All depends a little on whether you alter the existing API or just extend it. And yup, drat should do all that for you. – Dirk Eddelbuettel Mar 19 '16 at 18:43
  • Thanks for the edit, @NealFultz. I will update the body of the answer. – Dirk Eddelbuettel Mar 13 '20 at 12:21
  • 2
    Using the drat repository and linking to it via the `Additional_repositories:` is absolutely the best way I've seen to include a GitHub dependency. (Thanks @DirkEddelbuettel!) I went through a few iterations of various strategies before landing on the drat repo, and the drat repo simply works. Previously, I was trying to install the GH package to a temp folder, and updating the library search path to include the temp folder. While this worked locally, I always had issues with at least one OS checked by CRAN (and this was the method suggested by a CRAN reviewer). – Daniel D. Sjoberg Mar 13 '20 at 13:20
  • 2
    Hi @DanielSjoberg thanks for the endorsement! It so happens, and is little surprise, that I agree 100% as the _package mechansism_ is so well designed and tested that it delivers this robustly, whereas alternatives eventually flake out. `#FriendsDontLetFriendsUseRemote` – Dirk Eddelbuettel Mar 13 '20 at 13:34