7

In a package I'm developing, several different methods of estimating are provided. Typically, each of these depends on functionality provided by other packages (in some case, with version requirements).

Up to now, I've simply put all those packages in the "depends" section of my description file, but the number of packages that my own package now "depends" upon, even though for most users only one of those will ever be relevant, so I was hoping that packages could be installed/loaded only as needed? The documentation on writing R packages is sometimes a bit terse and has changed somewhat since recent R versions, so perhaps anyone here can provide the latest on that?

Just to illustrate, this is the typical pattern:

doSomethingImportant<-function(params, workerFunction)
{
   #blabla
   workerFunction(partofparams)
   #moreblabla
}

and then I'd have

wfA<-function(partofparams)
{
   #use something from package A
}

and

wfB<-function(partofparams)
{
   #use something from package B
}

And the user would call this function something like:

result<-doSomethingImportant(params, wfA)

With each user typically having a preference for one of the wfX. Ideally, when the user (first) uses one of the wfX, I'd like to have it installed/loaded on demand, but if that's not possible, I'd like a warning as soon as possible that it's going to fail (in fact, in my case, a lot of preparation may come before any actual attempt to call workerFunction from doSomethingImportant, which will all be lost if in the end the right package was not already present.

Can you suggest how to handle this properly and as user-friendly as possible?

juba
  • 47,631
  • 14
  • 113
  • 118
Nick Sabbe
  • 11,684
  • 1
  • 43
  • 57
  • 1
    List the packages in the `Suggests` field, and then in the function, test for their presence with `require` and respond appropriately. – hadley Mar 21 '13 at 13:15
  • Thanks, Hadley. Unfortunately, this makes the test for presence very late in the process. To make matters more complex: since these workerFunctions may well fail for other reasons than the absence of the packages (numerical reasons) but I wanted to handle this gracefully, the call is wrapped in a try. – Nick Sabbe Mar 21 '13 at 13:27
  • 1
    Figuring out how to do the test earlier in the process is just a programming problem. There are lots of solutions. For example, add the packages needed as a attribute of `wt*` and then test early in `doSomethingImportant` – hadley Mar 21 '13 at 15:44

0 Answers0