From wdunlap at tibco.com  Wed Apr 29 23:38:49 2015
From: wdunlap at tibco.com (William Dunlap)
Date: Wed, 29 Apr 2015 14:38:49 -0700
Subject: [Rd] R CMD check and missing imports from base packages
In-Reply-To: <55413E1A.9030804@fredhutch.org>
References: <CABtg=K=iq7XVY8NksW-gQq_zr7wk4329Sh67c55JxrFF2HDosQ@mail.gmail.com>
	<55413E1A.9030804@fredhutch.org>
Message-ID: <CAF8bMcb_3SuzLLwNg-znVByO2XtXsxwGnObMZ_4jmvv9oSHXLQ@mail.gmail.com>

> And in general a developer would avoid masking a function
> in a base package, so as not to require the user to distinguish
> between stats::density() and igraph::density(). Maybe the
> example is not meant literally.

The 'filter' function in the popular 'dplyr' package masks the one
that has been in the stats package forever, and they have nothing
in common, so that may give you an example.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Wed, Apr 29, 2015 at 1:24 PM, Martin Morgan <mtmorgan at fredhutch.org>
wrote:

> On 04/28/2015 01:04 PM, G?bor Cs?rdi wrote:
>
>> When a symbol in a package is resolved, R looks into the package's
>> environment, and then into the package's imports environment. Then, if the
>> symbol is still not resolved, it looks into the base package. So far so
>> good.
>>
>> If still not found, it follows the 'search()' path, starting with the
>> global environment and then all attached packages, finishing with base and
>> recommended packages.
>>
>> This can be a problem if a package uses a function from a base package,
>> but
>> it does not formally import it via the NAMESPACE file. If another package
>> on the search path also defines a function with the same name, then this
>> second function will be called.
>>
>> E.g. if package 'ggplot2' uses 'stats::density()', and package 'igraph'
>> also defines 'density()', and 'igraph' is on the search path, then
>> 'ggplot2' will call 'igraph::density()' instead of 'stats::density()'.
>>
>
> stats::density() is an S3 generic, so igraph would define an S3 method,
> right? And in general a developer would avoid masking a function in a base
> package, so as not to require the user to distinguish between
> stats::density() and igraph::density(). Maybe the example is not meant
> literally.
>
> Being able to easily flag non-imported, non-base symbols would definitely
> improve the robustness of package code, even if not helping the end user
> disambiguate duplicate symbols.
>
> Martin Morgan
>
>
>> I think that for a better solution, either
>> 1) the search path should not be used at all to resolve symbols in
>> packages, or
>> 2) only base packages should be searched.
>>
>> I realize that this is something that is not easy to change, especially 1)
>> would break a lot of packages. But maybe at least 'R CMD check' could
>> report these cases. Currently it reports missing imports for non-base
>> packages only. Is it reasonable to have a NOTE for missing imports from
>> base packages as well?
>>
>> [As usual, please fix me if I am missing or misunderstood something.]
>>
>> Thank you, Best,
>> Gabor
>>
>>         [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> 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: Arnold Building M1 B861
> Phone: (206) 667-2793
>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]



[Rd] R CMD check and missing imports from base packages
William Dunlap