William Dunlap
2015-Apr-29 21:38 UTC
[Rd] R CMD check and missing imports from base packages
> 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]]
Paul Gilbert
2015-Apr-30 00:12 UTC
[Rd] R CMD check and missing imports from base packages
On 04/29/2015 05:38 PM, William Dunlap wrote:>> 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.As I recall, several packages mask the simulate generic in stats, if you are looking for examples. Paul Gilbert> > 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]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
Gábor Csárdi
2015-Apr-30 03:07 UTC
[Rd] R CMD check and missing imports from base packages
On Wed, Apr 29, 2015 at 8:12 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote:> > As I recall, several packages mask the simulate generic in stats, if you > are looking for examples. >FWIW, here is a list of base* functions masked** by CRAN packages: https://github.com/gaborcsardi/rfunctions/blob/master/rfunctions.md Look at the long table in the end. simulate indeed comes up 16 times. (But read ** below.) * This only includes functions in base packages that are attached by default. ** The CRAN function names were taken from the manual page aliases, so a couple of them are not really function names, and some of them are probably not masking anything, but defining an S3 generic. This was a lot simpler than going over the namespaces of all CRAN packages. It seems that several base functions are masked, by several packages. I would need to get a better CRAN function list, though. Gabor [...]> Paul Gilbert >[[alternative HTML version deleted]]