(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 <ucfa...@gmail.com>
wrote:
On 27 August 2014 15:24, Hadley Wickham <h.wick...@gmail.com>
wrote:
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
NAMESPACE?
Yes.
(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
on)
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
interactively".
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
use those.
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.
Paul
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
away?
(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
Gavin
Hadley
-- http://had.co.nz/
-- Gavin Simpson, PhD
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________ R-devel@r-project.org
mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
