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

Duncan Murdoch murdoch.duncan at gmail.com
Wed Aug 3 01:45:34 CEST 2016


On 02/08/2016 6:34 PM, Dirk Eddelbuettel wrote:
>
> On 2 August 2016 at 18:13, Duncan Murdoch wrote:
> | 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.
>
> Debian has well over 20k packages, and they are tested this way.  You just
> need to show the will of testing in an _empty_ environment to ensure
> _everything_ that is needed is loaded.
>
> | 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?
>
> You seem to misunderstand that both you and I want
>
>   if (!requireNamespace("foo"))
>      stop("Package foo is needed for this example")
>
> (or alternative per-call tests) and that CRAN does not enforce either.
>
> CRAN, like Hadley, just closes its eyes, swallows hard, and then simply loads
> everything treating Suggests as if it were Depends.
>
> But it ain't. Suggests != Depends.
>
> Now clearer?


So really what you're suggesting is that CRAN should run tests with the 
suggested packages absent.  Presumably tests should also be run with 
them present.

But if they did that, the code that I want to write would call stop() 
and fail.  So we'd need some way to say "Let the user know they need 
'foo' to run this, but don't fail."  And we'd need to phase this in 
really gradually, because tons of packages are using code like my example.

You volunteered to help CRAN package checking.  Why not put together 
code to implement your idea, and see how big the problem would be to 
phase it in, by seeing how many packages fail under it?

Duncan Murdoch



More information about the R-package-devel mailing list