[R] Package dependencies in building R packages

[Philippe Grosjean]

On 30 Dec 2013, at 20:01, Axel Urbiz <axel.urbiz at gmail.com> wrote:

> Thanks for your kind response Duncan. To be more specific, I'm using the
> function mvrnorm from MASS. The issue is that MASS depends on survival and
> I have a function in my package named tt() which conflicts with a function
> in survival of the same name. I can think of 2 alternatives solutions to my
> problem, but I'm to an expert:

As of version 7.3-29 of MASS, it only depends on R (>= 3.0.0), grDevices, graphics, stats and utils. survival appears in the 'Suggests' field, which is very different. When you do 'library(MASS)' or 'require(MASS)', it does not import survival's NAMESPACE, at least at startup (and if it did, this would not cause interferences with your package… precisely the purpose of namespaces). It also does not attach survival to the search path, logically… and if it did, your package 'foo' would be attached higher on that search path, causing survival's tt() function being masked by your foo::tt() function, e.g., from the Global Environment with a warning. So, the only inconvenience in this case would be for users that need to use tt() from 'survival', and it would be better to always indicate explicitly foo::tt() or survival::tt() in order to eliminate the ambiguity.

> 1) Copy mvrnorm into my package, which I thought was not a good idea

Absolutely, think about future bug fixes. Moreover, it will not solve the problem in case someone attaches the 'survival' package higher in the search path than 'foo', e.g., using this in .GlobalEnv:

require(foo)
require(survival)
tt() # This would be survival::tt() that is called!

> 2) Rename my tt() function to something else in my package, but this is
> painful as I have it all over the place in other functions.

Definitely the best solution, providing your package is not on CRAN yet and has no other CRAN packages depending on it, and especially on your tt() function. Otherwise, you should declare tt() deprecated (see ?.Deprecated), make sure you inform maintainers of dependent packages of your changes, and wait long enough before removing tt() totally for user to adapt.

Otherwise, choose a good code editor, with regexpr search on all files in a directory makes it easy to change calls to tt() all over the places. RStudio, Emacs+ESS, Eclipse+StatEt, Komodo+SciViews-K come to me mind first, but there are many others.

Best,

Philippe

> Any suggestions would be much appreciated.
> 
> Best,
> Axel.
> 
> 
> On Mon, Dec 30, 2013 at 7:51 PM, Duncan Murdoch <murdoch.duncan at gmail.com>wrote:
> 
>> On 13-12-30 1:24 PM, Axel Urbiz wrote:
>> 
>>> Dear users,
>>> 
>>> My package {foo} depends on a function "miscFUN" which is on package
>>> {foo_depend}. This last package also depends on other packages, say {A, B,
>>> C}, but miscFUN is not dependent on A, B, C (only on foo_depend).
>>> 
>>> In my package {foo}, is there a way to only have it depend on the function
>>> miscFUN from {foo_depend} without having the user to have installed A, B,
>>> C? (as none of those packages are needed for my package to work properly).
>>> Also, is this a best practice?
>>> 
>> 
>> There's no way for your package to tell R to ignore the dependencies
>> declared by foo_depend.
>> 
>> If you really only need one function from that package, simply copy the
>> source of miscFUN into your package (assuming foo_depend's license permits
>> that).  But this is not best practice, unless that function is very simple.
>> Best practice is to declare your dependence by importing that function
>> from foo_depend.
>> 
>> Duncan Murdoch
>> 
>> 
>> 
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>