From friendly at yorku.ca  Sun Sep 15 18:52:47 2013
From: friendly at yorku.ca (Michael Friendly)
Date: Sun, 15 Sep 2013 12:52:47 -0400
Subject: [Rd] declaring package dependencies
In-Reply-To: <004801ceb09c$72f504d0$58df0e70$@mcmaster.ca>
References: <5231C3E3.3050007@yorku.ca>
	<5231FBD9.6050802@gmail.com>	<523305BB.7090802@yorku.ca>
	<52331857.8090904@gmail.com>
	<004801ceb09c$72f504d0$58df0e70$@mcmaster.ca>
Message-ID: <5235E5DF.1020806@yorku.ca>

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:

* 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.

> ### ** 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
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!


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.

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.
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.


-- 
Michael Friendly     Email: friendly AT yorku DOT ca
Professor, Psychology Dept. & Chair, Quantitative Methods
York University      Voice: 416 736-2100 x66249 Fax: 416 736-5814
4700 Keele Street    Web:   http://www.datavis.ca
Toronto, ONT  M3J 1P3 CANADA



[Rd] declaring package dependencies
Michael Friendly