[Rd] R package dependency issues when namespace is not attached

Martin Morgan mtmorgan at fhcrc.org
Mon May 14 00:06:04 CEST 2012


On 05/13/2012 01:39 PM, Duncan Murdoch wrote:
> On 12-05-13 4:06 PM, Martin Morgan wrote:
>> On 05/13/2012 12:14 PM, Jeroen Ooms wrote:
>>> On Sun, May 13, 2012 at 10:14 AM, Uwe Ligges
>>> <ligges at statistik.tu-dortmund.de> wrote:
>>>
>>>> I do not see any problem in R. If someone is going to import a
>>>> Namespace, he
>>>> or she has to do that via import directives in the NAMESPACE file. If
>>>> someone is going to have a package on the search path, he or she has to
>>>> require() it. The DESCRIPTION file is used to derive the dependency
>>>> structures among packages for installation order, check order etc.
>>>
>>> I am not sure everyone is aware of this. Many package authors seem to
>>> be assuming that having a package in the Depends field of the
>>> DESCRIPTION is a sufficient condition for having the dependency
>>> package available at runtime, regardless of how the function is
>>> invoked by the user. I think this is the usual meaning of a
>>
>> I think this is because name spaces are relatively new, so authors are
>> yet to realize the consequences of not importing the definitions their
>> package uses.
>
> They aren't that new, but I think our efforts at back-compatibility have
> slowed adoption. If we were more demanding of package developers, we
> wouldn't have this problem; but I think we'd have a lot fewer packages.
> Even with our current policy of aiming for back-compatibility we get a
> lot of complaints that we are asking too much.

perhaps it would be easy to provide a check (I realize this is close on 
the heels of the undefined global variables thread), along the lines of

 > library(codetools)
 > checkUsageEnv(getNamespace("bigdata"), suppressLocal=TRUE)
lasso.stars: no visible global function definition for 'glmnet'
lasso.stars: no visible global function definition for 'glmnet'

or to suggest a NAMESPACE, done imperfectly by

https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/codetoolsBioC

(username / password: readonly)

 > library(codetoolsBioC)
 > library(bigdata)
 > deps <- writeNamespaceImports("bigdata", file=stdout())
#Generated by codetoolsBioC version 0.0.16
#Timestamp: Sun May 13 15:01:12 2012

#Imports: glmnet, graphics, Matrix

importMethodsFrom(Matrix, mean, t)

importFrom(glmnet, glmnet)

importFrom(graphics, lines, par, plot)

>
>>
>> As a package developer, I want to have the code my package sees be
>> exactly what is needed, and no more. There are many good reasons for
>> this, including isolating as much as possible my code from changes in
>> other packages and minimizing the costs of symbol look-up. These issues
>> become increasing important as the hierarchy of package relationships
>> becomes deep.
>>
>> The best practice is for authors to import all necessary symbols, but no
>> more!
>
> I agree, but many authors don't want to think about things that way.
>
> Duncan Murdoch
>
>>
>> Martin
>>
>>> dependency. There are a lot of packages on CRAN that use Depends and
>>> are not explicitly importing anything. Among others, this holds for
>>> any package without a NAMESPACE file.
>>>
>>> Also looking at the definition of the 'Depends' field in the 'writing
>>> r extensions' manual there is not a single hint that Depends is not
>>> sufficient for having the package available at runtime, and any
>>> function that is used should still be manually imported or required()
>>> as you suggest.
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>


-- 
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793



More information about the R-devel mailing list