[R-pkg-devel] Handling Not-Always-Needed Dependencies?

[Duncan Murdoch]

On 02/08/2016 4:20 PM, Dirk Eddelbuettel wrote:
>
> On 2 August 2016 at 16:07, Duncan Murdoch wrote:
> | On 02/08/2016 1:41 PM, Dirk Eddelbuettel wrote:
> | >
> | > On 2 August 2016 at 13:12, Duncan Murdoch wrote:
> | > | On 02/08/2016 1:01 PM, Dirk Eddelbuettel wrote:
> | > | >
> | > | > On 2 August 2016 at 11:36, Joshua Ulrich wrote:
> | > | > | Maybe I'm missing something, but isn't that the point of calling
> | > | > | requireNamespace()?  For example:
> | > | > | if (requireNamespace("suggestedPackage"))
> | > | > |   stop("suggestedPackage required but not installed")
> | > | > |
> | > | > | That doesn't seem like a heavy burden for package writers when writing
> | > | > | infrequently used functions in their package.  You could even add the
> | > | > | install.packages command to the error message to instruct users to
> | > | > | install the required package.
> | > | >
> | > | > [...]
> | > | >
> | > | > | I personally would not want install.packages() to install packages I'm
> | > | > | unlikely to actually use.
> | > | > |
> | > | > | It's also not clear to me how importing rarely used functions causes
> | > | > | bloat, but installing all packages for all rarely-used functions does
> | > | > | not cause bloat.
> | > | >
> | > | > Sadly, some people whose advocacy is taken as religous gospel in some
> | > | > circles, particularly beginners, advocate pretty much that: treat Suggests:
> | > | > as Depends: and install it anyway because, hell, why would one tests.
> | > | >
> | > | > I regularly run (large) reverse depends checks against some of my more widely
> | > | > used packages and run into this all the time.
> | > | >
> | > | > We (as a community, including CRAN whose gatekeepers I have failed to
> | > | > convince about this on on multiple attempts) are doing this wrong.
> | > | > "Suggests:" really means optionally, rather than unconditionally.  But it
> | > | > would appear that you and I are about to only ones desiring that behaviour.
> | > |
> | > | I thought I understood Joshua's point (and agreed with it), but you also
> | > | seem to be agreeing with him and I don't understand at all what you're
> | > | saying.
> | > |
> | > | What is "this" in your last paragraph, that you have failed to convince
> | > | CRAN gatekeepers about?
> | >
> | > It is really simple:  Having _both_ Suggests: foo _and_ an unconditonal call
> | > to foo::bar() in the code.
> | >
> | > Whereas Josh and I argue that it needs to be conditional on requireNames()
> | > coming back TRUE.
> |
> | I am feeling particularly dense today.  What about "Having _both_
> | Suggests: foo _and_ an unconditonal call to foo::bar() in the code." did
> | you fail to convince CRAN about?  That it is a good thing, or a bad thing?
>
> It is a Really Bad Thing )TM) because I read Writing R Extensions as meaning
> that these ought to be tested for presence (as Suggests != Depends, so we
> cannot [rather: should not] assume them) yet package authors are sloppy (and
> CRAN let's them, being charged as facilitator to a crime here) and BAM I get
> a failing test as some bad, bad code unconditionally calls code that should
> only be called conditional on a suggested package actuallt being there.

Okay, now I think I understand, but I agree with CRAN.  It is not 
feasible to tell if the test happened somewhere in the code unless we 
enforce a particular way of writing the test.

I would object if I had to write if (requireNamespace("foo")) multiple 
times just to satisfy CRAN's test, when any sane human could tell that 
the first test was sufficient.

For example, if my package Suggests: foo, I should be able to write

if (!requireNamespace("foo"))
   stop("Package foo is needed for this example")

and then merrily call foo::bar() as many times as I like.

Or am I still misunderstanding you?  What particular thing should CRAN 
change?

Duncan Murdoch