[Rd] Re R CMD check checking in development version of R
ucfagls at gmail.com
Thu Aug 28 05:33:12 CEST 2014
On Aug 27, 2014 5:24 PM, "Hadley Wickham"
> I'd say: Depends is a historical artefact from ye old days before
> package namespaces. Apart from depending on a specific version of R,
> you should basically never use depends. (The one exception is, as
> mentioned in R-exts, if you're writing something like latticeExtras
> that doesn't make sense unless lattice is already loaded).
Keeping this nuance in mind when when discussing Depends vs Imports is
important so as to not suggest that there isn't any reason to use Depends
I am in full agreement that its use should be limited to exceptional
situations, and have modified my packages accordingly.
> > This check (whilst having found some things I should have imported and
> > didn't - which is a good thing!) seems to be circumventing the
> > having something in Depends. Is Depends going to go away?
> I don't think it's going to go away anytime soon, but you should
> consider it to be largely deprecated and you should avoid it wherever
> >> (And really you shouldn't have any packages in depends, they should
> >> all be in imports)
> > I disagree with *any*; having say vegan loaded when one is using
> > a design decision as the latter borrows heavily from and builds upon
> > In general I have moved packages that didn't need to be in Depends into
> > Imports; in the version I am currently doing final tweaks on before it
> > to CRAN I have remove all but vegan from Depends.
> I think that is a reasonable use case for depends. Here's the exact
> text from R-exts: "Field ‘Depends’ should nowadays be used rarely,
> only for packages which are intended to be put on the search path to
> make their facilities available to the end user (and not to the
> package itself): for example it makes sense that a user of package
> latticeExtra would want the functions of package lattice made
> Personally I avoid even this use, requiring users of my packages to be
> explicit about exactly what packages are on the search path. You are
> of course welcome to your own approach, but I think you'll find it
> will become more and more difficult to maintain in time. I recommend
> that you bite the bullet now.
> Put another way, packages should be extremely conservative about
> global side effects (and modifying the search path is such a
[[alternative HTML version deleted]]
More information about the R-devel