And if, like me, you always forget which of Depends and Imports is the
one you are supposed to be using, the mnemonic device is "DEPends is
DEPrecated[1], IMPorts is IMPortant."
Barry
[1] kinda.
On Thu, Aug 28, 2014 at 4:33 AM, Gavin Simpson wrote:
> On Aug 27, 2014 5:24 PM, "Hadley Wickham"
> peter dalgaard
> on Wed, 27 Aug 2014 21:09:47 +0200 writes:
> On 27 Aug 2014, at 16:48 , Hadley Wickham wrote:
>>> I think the right answer _is_ to export the lazy data; the question is
how to do it. There's nothing particularly strange about exporting
non-functions ("le
On 08/27/2014 08:33 PM, Gavin Simpson wrote:
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
mentio
>>> 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 does
On 08/28/2014 05:52 AM, Hadley Wickham wrote:
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
Here is one rationale for the change, which was useful for my understanding
This arises in the survival package in the survexp function:
survexp <- function(formula, data, weights, subset, na.action,
ratetable=survexp.us)
The argument has been changed to survival::survexp.us, soon to be
On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote:
> On 27 August 2014 15:24, Hadley Wickham 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 im
This is a nice explanation of the Imports/Depends distinction. It
ought to go into the Extensions ref manual imho.
Cheers,
Bert
Bert Gunter
Genentech Nonclinical Biostatistics
(650) 467-7374
"Data is not information. Information is not knowledge. And knowledge
is certainly not wisdom."
Clifford
Hi,
I second Bert's comment. I would like to go even farther and suggest that it
would be really useful if one of the R gurus (like Simon) wrote a relatively
non-technical article in the R journal on this topic of
"Depends/Imports/Suggested." Someone like myself would benefit immensely.
Thank
>From a developers point of view, these days a less ambiguous name for
'Depends' would be 'Attaches'.
...or maybe even 'ImportsAndAttaches' with 'ImportsOnly' (for 'Imports').
I think Simon phrased it very well, and as others already pointed out,
having one package attaching additional ones certa
I fully agree.
This is how I have come to understand Depends vs Imports and why I
currently will not be removing vegan from Depends for my analogue package.
This is also why I was pushing back against the notion that was voiced
early in this thread that *nothing* should be in Depends.
Cheers
G
Gavin,
I admit to not knowing the details of your package, but do users commonly
need to use symbols from other package *in calls to functions exported by
your package*? If so, you're in the situation Martin (Morgan) described,
which is one I think everyone agrees Depends is appropriate for.
If t
Gabriel,
That is not my understanding of this at all. I could hide the fact that I
was using vegan under the hood, supplying methods for its generics and by
exporting the generic I imported from vegan, etc. But you are missing the
point that I see users of my package, because I envisioned close
in
Gavin,
I don't claim to be the arbiter of good package design. The following are
my opinions, along with the reasons I hold them.
If you are also importing vegan, which I think everyone agreed needs to
happen, the only thing putting vegan in Depends does is attach the package.
This is something u
Yes, Depends certainly has a role. The ability of one package to
automatically provide all the facilities of another package to the
user is important. There are many situations where the functionality
you want to provide to the user is split among multiple packages.
For example,
1. xts uses zoo a
(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
wrote:
On 27 August 2014 15:24, Hadley
16 matches
Mail list logo
