One more follow-up -- will I now need to include a library() statement in
each function?
--j
On Sun, Oct 20, 2013 at 3:58 PM, Gabor Grothendieck <ggrothendi...@gmail.com
> wrote:
> On Sun, Oct 20, 2013 at 4:49 PM, Duncan Murdoch
> <murdoch.dun...@gmail.com> wrote:
> > On 13-10-20 4:43 PM, Jonathan Greenberg wrote:
> >>
> >> I'm working on an update for my CRAN package "spatial.tools" and I
> noticed
> >> a new warning when running R CMD CHECK --as-cran:
> >>
> >> * checking CRAN incoming feasibility ... NOTE
> >> Maintainer: 'Jonathan Asher Greenberg <spatial-to...@estarcion.net>'
> >> Depends: includes the non-default packages:
> >> 'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach'
> >> 'doParallel' 'rgeos'
> >> Adding so many packages to the search path is excessive
> >> and importing selectively is preferable.
> >>
> >> Is this a warning that would need to be fixed pre-CRAN (not really sure
> >> how, since I need functions from all of those packages)? Is there a way
> >> to
> >> import only a single function from a package, if that function is a
> >> dependency?
> >
> >
> > You really want to use imports. Those are defined in the NAMESPACE file;
> > you can import everything from a package if you want, but the best style
> is
> > in fact to just import exactly what you need. This is more robust than
> > using Depends, and it doesn't add so much to the user's search path, so
> it's
> > less likely to break something else (e.g. by putting a package on the
> path
> > that masks some function the user already had there.)
>
> That may answer the specific case of the poster but how does one
> handle the case
> where one wants the user to be able to access the functions in the
> dependent package.
>
> For example, sqldf depends on gsubfn which provides fn which is used
> with sqldf to
> perform substitutions in the SQL string.
>
> library(sqldf)
> tt <- 3
> fn$sqldf("select * from BOD where Time > $tt")
>
> I don't want to ask the user to tediously issue a library(gsubfn) too since
> fn is frequently needed and for literally years this has not been
> necessary.
> Also I don't want to duplicate fn's code in sqldf since that makes the
> whole
> thing less modular -- it would imply having to change fn in two places
> if anything
> in fn changed.
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>
--
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urbana-Champaign
259 Computing Applications Building, MC-150
605 East Springfield Avenue
Champaign, IL 61820-6371
Phone: 217-300-1924
http://www.geog.illinois.edu/~jgrn/
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307, Skype: jgrn3007
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
