R devel - May 2012 - R package dependency issues when namespace is not attached

I have always assumed that having a package in the 'Depends' field
would automatically also?import?the namespace. However, it seems that
in R 2.15, dependencies do not become available until the package is
actually?attached?to the searchpath. Is this intended behavior?

The problem appears as follows: Suppose there is a package 'Child'
which?Depends, but does not explicitly import?a package called
'Parent' and contains a function that calls out to an object in the
namespace of 'Parent'. When this function is called without attaching
'Child' to the search path, the function in 'Parent' cannot be
found.

Here an example from the manual of the?bigdata?package, but the
problem is very widespread:

x = matrix(rnorm(50*80),50,80)
beta = c(3,2,1.5,rep(0,77))
y = rnorm(50) + x%*%beta
z1 = bigdata::lasso.stars(x,y)

The example fails because lasso.stars depends on 'glmnet' which is not
loaded until?bigdata?is attached. The only way to be able to call
lasso.stars?is to actually attach the?bigdata?package:

library(bigdata)
z1 = bigdata::lasso.stars(x,y)

Now to further complicate things, it seems that this problem is
inherited to any 'grandchild' package that?imports, in this case, the
lasso.stars function. I have a hard time finding a good example but I
am sure they are out there.

Is this a bug? I know that it can be avoided by asking package authors
to use Imports instead of Depends, but in practice the majority of the
packages on CRAN still use Depends. It seems like the problem is
easily fixed if R would automatically import the namespace of any
Depends packages into to the child package namespace?

On 12-05-13 3:15 AM, Jeroen Ooms wrote:
> I have always assumed that having a package in the 'Depends' field
> would automatically also import the namespace. However, it seems that
> in R 2.15, dependencies do not become available until the package is
> actually attached to the searchpath. Is this intended behavior?
>
> The problem appears as follows: Suppose there is a package 'Child'
> which Depends, but does not explicitly import a package called
> 'Parent' and contains a function that calls out to an object in the
> namespace of 'Parent'. When this function is called without
attaching
> 'Child' to the search path, the function in 'Parent' cannot
be found.
>
> Here an example from the manual of the bigdata package, but the
> problem is very widespread:
>
> x = matrix(rnorm(50*80),50,80)
> beta = c(3,2,1.5,rep(0,77))
> y = rnorm(50) + x%*%beta
> z1 = bigdata::lasso.stars(x,y)
>
> The example fails because lasso.stars depends on 'glmnet' which is
not
> loaded until bigdata is attached. The only way to be able to call
> lasso.stars is to actually attach the bigdata package:
>
> library(bigdata)
> z1 = bigdata::lasso.stars(x,y)
>
> Now to further complicate things, it seems that this problem is
> inherited to any 'grandchild' package that imports, in this case,
the
> lasso.stars function. I have a hard time finding a good example but I
> am sure they are out there.
>
> Is this a bug? I know that it can be avoided by asking package authors
> to use Imports instead of Depends, but in practice the majority of the
> packages on CRAN still use Depends. It seems like the problem is
> easily fixed if R would automatically import the namespace of any
> Depends packages into to the child package namespace?
Not sure if it's a bug, but the correct solution in bigdata is to import 
the glmnet function in its NAMESPACE.  Then the namespace that gets 
loaded when you type bigdata::lasso.stars will be able to see the glmnet 
function.

Perhaps Depends in the DESCRIPTION file should do the import 
automatically, but it will be faster to import just one function than 
everything from a package that has a lot of exports.  So maybe it's a 
bug because we don't do that, but I think there would be complaints if 
we did.

On the other hand, if bigdata::lasso.stars loaded glmnet onto the search 
path, I think that would be a bug.  The search path belongs to the user, 
not to R, and the user might have used the :: notation to avoid messing 
with it.

Duncan Murdoch