From ggrothendieck at gmail.com  Fri Aug 29 01:26:32 2014
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Thu, 28 Aug 2014 19:26:32 -0400
Subject: [Rd] Re R CMD check checking in development version of R
In-Reply-To: <CAAHES9x2otsMnzqgLymx_b_xqbJPGr7Uv4t5F9Bqs0OPqyJLKg@mail.gmail.com>
References: <CAAHES9xbHJLUbzLzS7C2tTaODv=d_JV5ds09ZFdA6Bv+uBSYEA@mail.gmail.com>
	<CABdHhvG7ahtFhBOCRU9X2KRR2Z30S1gE_F66m0W=91wpkbvyOA@mail.gmail.com>
	<CAAHES9yzPkidSVAW6=BE689mrfo7Bv_MHZ=WzanHwpctGC21Tg@mail.gmail.com>
	<79381712-FCA3-4995-83BC-956270EDABC4@r-project.org>
	<CACk-te1fEUTzqwEF1EBBtaBTy3QvK13ARr2tOsYjda3Q++_dvA@mail.gmail.com>
	<CAAHES9x2otsMnzqgLymx_b_xqbJPGr7Uv4t5F9Bqs0OPqyJLKg@mail.gmail.com>
Message-ID: <CAP01uRkmpZLmg3ab20OCQzsv1uEDGDq+8bJzYcvHtfihOgdM8w@mail.gmail.com>

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 and the user ought to be able to use all the
functionality of zoo when they issue a library(zoo) call.  The
alternatives are that the user must tediously issue library(zoo) every
time they issue library(xts) or else that the zoo code be copied or
partially replicated into xts which would be undesirable
maintenance-wise.

2. Another example is sqldf.  The user wants to be able to use fn$ and
other string manipulation functions in gsubfn when using sqldf in
order to perform string substitution on the SQL statement.  Also its
desirable to be able to directly access sqlite which means the user
needs access to RSQLite.

3. At one time one could just issue library(ggplot2) but now that
ggplot2 does not use Depends for scales one annoyingly needs to issue
library(scales) if one wants to specify a scale.   I use ggplot2
enough that I can remember it despite the ongoing annoyance but I
would hate to think that every package with split functionality
suddenly adds such onerous requirements onto all its users.  (I am not
really picking on ggplot2 which is a very nice package - just this one
aspect.)

I am not sure but there might be additional problems if the secondary
package defines an S3 generic that the primary package needs to use if
one does not use Depends.


On Thu, Aug 28, 2014 at 2:43 PM, 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



-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com



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