[Rd] declaring package dependencies

[Duncan Murdoch]

On 13-09-15 12:52 PM, Michael Friendly wrote:
> On 9/13/2013 12:15 PM, John Fox wrote:
>> If I understand this thread, Michael's package doesn't use loglm() -- it
>> provides methods for objects produced by loglm() and hence "Enhances" the
>> package.
> Well, here's the rub: vcdExtra uses MASS::loglm() in examples, and also
> in R code,
> where it provides new S3 methods for loglm objects.  And, this whole
> problem only arose
> after vcd (on which I Depend), modified its Imports to:
>
> Imports: utils, MASS, grDevices, colorspace
> where, previously, MASS had been a Depends (or Suggests?) there.
>
>
> For my examples, the old Suggests: MASS worked, but now I've used
> require(MASS) in
> each of those examples.  However, the use in R code also triggered an
> error on loglm, even
> when I added
> Enhances: MASS
> to DESCRIPTION.
>
> OK, so I switched to using
> Imports: MASS
> but even that doesn't cure the problem alone.  I then got:

That just declares that MASS needs to be available, or installation of 
your package should abort.  It doesn't actually import anything.  You 
declare what parts of MASS you want to import in your NAMESPACE file.

>
> * checking dependencies in R code ... NOTE
> Namespace in Imports field not imported from: 'MASS'
>     All declared Imports should be used.
> See the information on DESCRIPTION files in the chapter 'Creating R
> packages' of the 'Writing R Extensions' manual.
>
> but then an Error when an example using the function which called loglm()
> directly was run.

If you had in your NAMESPACE file:

importFrom(MASS, loglm)

you wouldn't get the above error.

>
>> ### ** Examples
>>
>> data(Titanic, package="datasets")
>> # variables are in the order Class, Sex, Age, Survived
>> tt <- seq_loglm(Titanic)
> 1   model.string:  = Class
> Error in eval(expr, envir, enclos) : could not find function "loglm"
> Calls: seq_loglm -> eval -> eval

This looks like you're doing something tricky (those two evals), but 
normally if you are only calling loglm from your own internal code, you 
wouldn't need anything else.

If you have an explicit call to loglm in your example, then it needs to 
be available to the user, so you could use the MASS::loglm notation, or 
(and this is probably a worse choice) you could export loglm from your 
package.


> Execution halted
>
>
> So, as several people have suggested, I changed to use MASS::loglm() in
> code,
> though it still perplexes me why this is necessary.  At any rate, this
> now passes R devel.
> Whew!

That will also work, though the importFrom solution is slightly cleaner 
and faster.  The :: operator takes time to evaluate; with importFrom, it 
is effectively evaluated just once, when your package loads.  (Of 
course, if MASS::loglm is only rarely used, you might not want to load 
it every time, and MASS::loglm might be the better choice.)

>
>
> Thanks to a suggestion from Mattew Dowle, I'm now using winbuilder (thx,
> Uwe for this!)
> and can get rather quick (< 30 min.) feedback on an R-devel build,
> whereas the
> R-Forge build cycle often takes a day.

Yes, thanks Matthew for pointing this out, and Uwe for doing it.

>
> So, my workflow is  now
> - R CMD check on local version in StatET
> - If OK, send to winbuilder, http://win-builder.r-project.org/upload.aspx
> - If OK, commit to R-Forge, and perhaps submit to CRAN if this is the
> final rev
> in a development cycle.
>
> But I still feel like I'm spending too much time on satisfying the
> unknown, new
> requirements of CRAN checks.  As Dirk said (also deserving to be a fortune),
>
>> Absent a time machine or psychic powers, I do not see how package developers
>> can reasonably be expected to cope with this.

These checks are not capricious, they are making your package better. 
For the present example, you were doing things in a way that just 
happened to work because of the way vcd was written.  When it changed, 
your package broke.  If you follow the new instructions, your package 
will be robust against changes like that.

> The effort by R Core members that goes into R and CRAN is certainly
> herculean and I
> appreciate it very much.  Like Dirk, I'm just looking for a little more
> predictability as
> CRAN evolves.

It is more the evolution of R that you are seeing, with CRAN serving as 
a giant testbed.  As we identify predictable coding errors in packages, 
we add checks to R.  If you have made those coding errors, then 
eventually you'll need to fix them.  CRAN is just asking you to do it 
sooner, rather than later.  However, I would guess that if you have an 
urgent fix in the package you are uploading, and something is going to 
stop you from fixing the newly identified problem, they'll be 
sympathetic to the need to allow your package to fix the urgent problem 
and keep the other one unfixed for a short time.

Duncan Murdoch