[Rd] Re R CMD check checking in development version of R
pgilbert902 at gmail.com
Fri Aug 29 04:55:04 CEST 2014
(Please correct me if I'm wrong. I thought I mostly understood this,
finally, but I've made the mistake of thinking I understood something
too many times before.)
On 08/28/2014 10:39 AM, Simon Urbanek wrote:
> On Aug 27, 2014, at 6:01 PM, Gavin Simpson <ucfagls at gmail.com>
>> On 27 August 2014 15:24, Hadley Wickham <h.wickham at gmail.com>
>>>> Is that the cause of these NOTEs? Is the expectation that if I
>>>> am using a function from a package, even a package that I have
>>>> in Depends:, that I have to explicitly declare these imports in
>>> (Otherwise your package won't work if it's only attached and not
>>> loaded. i.e. if someone does analogue::foo() only the imported
>>> functions are available, not the functions in packages you depend
>> Cheers Hadley. Thanks for the confirmation, but...
>> ...I don't get this; what is the point of Depends? I thought it was
>> "my package needs these other packages to work, i.e. be loaded".
>> Hence it is user error (IMHO ;-) to do `analogue::foo()` without
>> having the dependencies loaded too.
> No. The point of Depends is that if your package is attached, it also
> attaches the other packages to make them available for the user.
> Essentially you're saying "if you want to use my package
> interactively, you will also want to use those other packages
I agree that "interactively" catches the flavour of what Depends does,
but technically that is the wrong word. The important point is whether
the functions in a Depended upon package should be available to the user
directly without them needing to use library() or require() to make them
available, in an interactive session or a batch job.
>You still need to use import() to define what exactly
> is used by your package -
Amplifying a bit: By import() in the NAMESPACE, which you need whether
you have Depends or Imports in the DESCRIPTION file, you ensure that the
functions in your package use the ones in the package imported and do
not get clobbered by anything the user might do. The user might redefine
functions available to the interactive session, or require() another
package with functions having the same names, and those are the ones his
interactive direct calls will find, but your package functions will not
People are sure to have differences of opinion about the trade-off
between the annoyance of having to specifically attach packages being
used, and the clarity this provides. At first I was really annoyed, but
have eventually decided I do like the clarity.
In my experience it turns out to be surprisingly rare that you need
packages in Depends, but there are legitimate cases beyond the annoyance
case mentioned above. I think if you are putting packages in Depends you
really do want to have a very good understanding of why you are doing
that. If you use Depends then you are inviting support difficulties.
Users will contact you about bugs in the package you attach, even though
your package may not use the broken functions. If they attach the
package themselves then they are much more likely to understand who they
should contact. Core seems to have forgotten to take credit for trying
to make life easier for package developers.
as opposed to what you want to be available
> to the user in case it is attached.
> Cheers, Simon
>> This check (whilst having found some things I should have imported
>> and didn't - which is a good thing!) seems to be circumventing the
>> intention of having something in Depends. Is Depends going to go
>>> (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
>> analogue is a design decision as the latter borrows heavily from
>> and builds upon vegan. 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 goes to CRAN I have remove all but
>> vegan from Depends.
>> Or am I thinking about this in the wrong way?
>> Thanks again
>>> -- http://had.co.nz/
>> -- Gavin Simpson, PhD
>> [[alternative HTML version deleted]]
>> R-devel at r-project.org mailing list
> ______________________________________________ R-devel at r-project.org
> mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
More information about the R-devel