[Rd] Re R CMD check checking in development version of R

Fri Aug 29 00:36:56 CEST 2014

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 users can easily do themselves, and which *may* not be
required to use your package (I don't know). As such, using Depends limits
the user's agency/control over their session in return for what I would
argue may (depending on circumstance) be a nominal benefit at best.

Continued inline.

On Thu, Aug 28, 2014 at 2:42 PM, Gavin Simpson <ucfagls at gmail.com> wrote:

> 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
> interlinking with the functionality provided by vegan, wanting to use vegan
> interactively with many of the objects that functions in analogue create.
>

Well sure, but if that is the case, they know they want to call functions
in vegan, so I would think that they would expect to load vegan and not
really think twice about having to do so, making your Depends irrelevant.

The other question is, can analogue be used without vegan? If it can,
*forcing* users to have vegan attached it doesn't seem desirable. Depends
gives users less power to avoid or resolve symbol conflicts.

Point in case, there is a logging package called log4r which overrides the
'debug' (madness, I know) symbol, and I once had a package (call it PkgA)
loaded which Depends on log4r it, with good reason, even, since you are
expected to pass a user-created logging object of some kind to the to
PkgA's functions. This meant that the base-R debug function was
*mandatorally* masked. This is very bad for the user (me), and honestly if
the author hadn't agreed to change the Dependency I wouldn't even consider
using the package.

If log4r has been imported, I wouldn't have cared at all, as I would have
been in control of whether the package was attached or not, and when.

I'm sure (hope) that vegan doesn't do anything this egregious, and if not,
your use of Depends isn't The-Most-Horrible-Thing-Ever. I'd argue that it
is undesirable, but relatively mildly so, and others may argue not at all.

>
> I do feel this aversion to Depends is being taken too far by some. Simon's
> articulation in this thread of what Depends means (to him) is the closest I
> have seen to how I have interpreted things. That's also about as close to
> official wisdom that I have seen beyond what is in Writing R Extensions.
>

If the official wisdom from R-core disagrees with me, that is probably a
good reason not to listen to me. I was under the impression that Depends
was not recommended except in cases like the described by Mr. Morgan.

Best,
~G

On 28 August 2014 15:14, Gabriel Becker <gmbecker at ucdavis.edu> wrote:

> 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 the above is not the case, and you're arguing it's simply convenient
> for users because it's very common for them to use top level functions from
> both in the same analysis, the case for Depends is not as strong. In that
> case, the official wisdom, AFAIK, is that Depends is not warranted.
>
> ~G
>
>
> On Thu, Aug 28, 2014 at 11:43 AM, Gavin Simpson <ucfagls at gmail.com> wrote:
>
>> 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
>>
>>
>> On 28 August 2014 08:47, Bert Gunter <bgunter at gene.com> wrote:
>>
>> > 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 Stoll
>> >
>> >
>> >
>> >
>> > On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek
>> > <simon.urbanek at r-project.org> wrote:
>> > >
>> > > On Aug 27, 2014, at 6:01 PM, Gavin Simpson <ucfagls at gmail.com> wrote:
>> > >
>> > >> On 27 August 2014 15:24, Hadley Wickham <h.wickham at 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". You still
>> need
>> > to use import() to define what exactly is used by your package - 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 at r-project.org mailing list
>> > >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> > >>
>> > >
>> > > ______________________________________________
>> > > R-devel at r-project.org mailing list
>> > > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>>
>>
>>
>> --
>> Gavin Simpson, PhD
>>
>>         [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
>

-- 
> Gavin Simpson, PhD
>

-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

	[[alternative HTML version deleted]]